DHCP и APIPA протокол динамической настройки узла - алгоритмы работы

Привет, сегодня поговорим про dhcp, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое dhcp, протокол динамической настройки узла, apipa , настоятельно рекомендую прочитать все из категории Компьютерные сети.

DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла ) — сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемомусерверу DHCP и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве сетей TCP/IP.

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

APIPA (Automatic Private IP Addressing) - это механизм автоматической настройки IP-адресов в локальных сетях, который используется в операционных системах Windows, если не удалось получить IP-адрес от DHCP сервера.

Когда компьютер или другое устройство подключается к сети и не может обнаружить DHCP сервер или получить от него IP-адрес, оно автоматически присваивает себе IP-адрес из специально зарезервированного диапазона адресов, который находится в диапазоне от 169.254.0.1 до 169.254.255.254. Это позволяет устройствам в локальной сети связываться друг с другом без необходимости наличия активного DHCP сервера. Однако устройства, использующие APIPA, не могут подключаться к устройствам в других сетях или в Интерне

История

Стандарт протокола DHCP был принят в октябре 1993 года. Действующая версия протокола (март 1997 года) описана в RFC 2131. Новая версия DHCP, предназначенная для использования в среде IPv6, носит название DHCPv6 и определена в RFC 3315 (июль 2003 года).

Распределение IP-адресов

Протокол DHCP предоставляет три способа распределения IP-адресов:

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

Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов. Это производится при помощи протокола обновления DNS, описанного в RFC 2136.

1.2. Постановка задачи

Протокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Параметры стека TCP/IP, предоставляемые протоколом DHCP перечислены в приложении A. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров.

Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов.

1.3. Терминология

В данном документе применены следующие определения:

1.4. Цели DHCP.

Ниже предлагается список основных задач DHCP.

DHCP должен:

Опции DHCP

Помимо IP-адреса, DHCP также может сообщать клиенту дополнительные параметры, необходимые для нормальной работы в сети. Эти параметры называются опциями DHCP. Список стандартных опций можно найти в RFC 2132.

Опции – строки переменной длины, состоящие из октетов. Первый октет - код опции, второй октет – количество следующих октетов, остальные октеты зависят от кода опции.

Например, опция “DHCP Message Type” при отправке сообщения “Offer” будет выглядеть так : 0x35,0x01,0x02, где 0x35 – код опции “DHCP Message Type” , 0x01 – означает, что далее идет только один октет, 0x02 – значение “Offer”.

Некоторыми из наиболее часто используемых опций являются:

• IP-адрес маршрутизатора по умолчанию;
• маска подсети;
• адреса серверов DNS;
• имя домена DNS.

Некоторые поставщики программного обеспечения могут определять собственные дополнительные опции DHCP.

В следующих таблицах перечислены доступные DHCP опции, как указано в RFC2132:

RFC1497 расширения поставщиков программного обеспечения.

Используется для дополнения других опций, чтобы они выравнивались по границе слова.

Должн быть отправлен после  опции “router” (опция 3), если оба включены.

Доступные маршрутизаторы  должны быть перечислены в порядке предпочтения.

Доступные серверы  для синхронизации  должны быть перечислены в порядке предпочтения.

Доступные IEN 116 – имена серверов, должны быть перечислены в порядке предпочтения.    

Длина загрузочного образа в 4-килобайтных блоках.

Путь до места хранения аварийных дампов.

Параметры IP-уровня клиента.

Параметры интерфейса Ip-уровня.

Параметры интерфейса уровня связи.

TCP –параметры.

Параметры сервисов и приложений.

DHCP – расширения.

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

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

Устройство протокола

Протокол DHCP является клиент-серверным, то есть в его работе участвуют клиент DHCP и сервер DHCP. Передача данных производится при помощи протокола UDP. По умолчанию запросы от клиента делаются на 67 порт к серверу, сервер в свою очередь отвечает на порт 68 к клиенту, выдавая адрес IP и другую необходимую информацию, такую, как сетевую маску, маршрутизатор и серверы DNS.

Структура сообщений DHCP

Все сообщения протокола DHCP разбиваются на поля, каждое из которых содержит определенную информацию. Все поля, кроме последнего (поля опций DHCP), имеют фиксированную длину.

Пример процесса получения адреса (алгоритм работы DHCP)

Рассмотрим пример процесса получения IP-адреса клиентом от сервера DHCP. Предположим, клиент еще не имеет собственного IP-адреса, но ему известен его предыдущий адрес — 192.168.1.100. Процесс состоит из четырех этапов.

Обнаружение DHCP

Вначале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (так как компьютер еще не имеет собственного IP-адреса), а в качестве адреса назначения — широковещательный адрес 255.255.255.255.

Клиент заполняет несколько полей сообщения начальными значениями:

• В поле xid помещается уникальный идентификатор транзакции, который позволяет отличать данный процесс получения IP-адреса от других, протекающих в то же время.
• В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента.
• В поле опций указывается последний известный клиенту IP-адрес. В данном примере это 192.168.1.100. Это необязательно и может быть проигнорировано сервером.

Сообщение DHCPDISCOVER может быть распространено за пределы локальной физической сети при помощи специально настроенных агентов ретрансляции DHCP, перенаправляющих поступающие от клиентов сообщения DHCP серверам в других подсетях.

Не всегда процесс получения IP адреса начинается с DHCPDISCOVER. В случае, если клиент ранее уже получал IP адрес и срок его аренды еще не прошел — клиент может пропустить стадию DHCPDISCOVER, начав с запроса DHCPREQUEST отправляемого с идентификатором сервера, который выдал адрес в прошлый раз. В случае же отсутствия ответа от DHCP сервера, выдавшего настройки в прошлый раз, клиент отправляет DHCPDISCOVER. Тем самым клиент начинает процесс получения с начала, обращаясь уже ко всем DHCP серверам в сегменте сети.

Предложение DHCP

Получив сообщение от клиента, сервер определяет требуемую конфигурацию клиента в соответствии с указанными сетевым администратором настройками. В данном случае DHCP-сервер согласен с запрошенным клиентом адресом 192.168.1.100. Сервер отправляет ему ответ (DHCPOFFER), в котором предлагает конфигурацию. Предлагаемый клиенту IP-адрес указывается в поле yiaddr. Прочие параметры (такие, как адреса маршрутизаторов иDNS-серверов) указываются в виде опций в соответствующем поле.

Это сообщение DHCP-сервер отправляет хосту, пославшему DHCPDISCOVER, на его MAC, при определенных обстоятельствах сообщение может распространяться как широковещательная рассылка. Клиент может получить несколько различных предложений DHCP от разных серверов; из них он должен выбрать то, которое его «устраивает».

Запрос DHCP

Выбрав одну из конфигураций, предложенных DHCP-серверами, клиент отправляет запрос DHCP (DHCPREQUEST). Он рассылается широковещательно; при этом к опциям, указанным клиентом в сообщении DHCPDISCOVER, добавляется специальная опция — идентификатор сервера — указывающая адрес DHCP-сервера, выбранного клиентом (в данном случае — 192.168.1.1).

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

Наконец, сервер подтверждает запрос и направляет это подтверждение (DHCPACK) клиенту. После этого клиент должен настроить свой сетевой интерфейс, используя предоставленные опции.

Вид сообщений

Ниже приведены значения каждого поля для каждого из отправляемых в процессе сообщений DHCP.

Прочие сообщения DHCP

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

Отказ DHCP

Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.

Сообщение отмены DHCP (DHCPNAK). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.

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

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

Информация DHCP

Сообщение информации DHCP (DHCPINFORM) предназначено для определения дополнительных параметров TCP/IP (например, адреса маршрутизаторапо умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса.

Реализации

Компания Microsoft впервые включила сервер DHCP в поставку серверной версии Windows NT 3.5, выпущенной в 1994 году. Начиная с Windows 2000 Server реализация DHCP-сервера от Microsoft позволяет динамически обновлять записи DNS, что используется в Active Directory.

Internet Systems Consortium выпустил первую версию ISC DHCP Server (для Unix-подобных систем) 6 декабря 1997 года. 22 июня 1999 года вышла версия 2.0, более точно соответствующая стандарту.

Компания Cisco включила сервер DHCP в Cisco IOS 12.0 в феврале 1999 года. Sun добавила DHCP-сервер в Solaris 8 в июле 2001 года.

В настоящее время существуют реализации сервера DHCP для ОС Windows в виде отдельных программ, в том числе открытых , позволяющих выполнять роль сервера DHCP компьютерам под управлением не серверных версий данной ОС.

Недостатки DHCP

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

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

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

* * *

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

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

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

Распределение IP-адресов: возможны варианты

BOOTP, DRARP, TFTP, ICMP, NIP - вероятно, это еще не полный перечень протоколов, в той или иной мере претендующих на решение задачи управления IP-адресами и конфигурацией в сетевой среде. Не исключено, что после стандартизации DHCP довольно быстро вытеснит их со сцены, однако на сегодняшний день многие из названных протоколов нередко упоминаются в литературе и используются в готовых продуктах.

Подобно DHCP, протокол Bootstrap Protocol (BOOTP) сегодня также имеет статус предварительного стандарта и рекомендован к применению консорциумом IETF. Именно его следует считать непосредственным предшественником DHCP. Появившиеся в 1993 г. дополнения расширили перечень конфигурационных параметров, охватываемых протоколом BOOTP. Более того, к настоящему времени даже предложена модификация BOOTP, поддерживающая динамическое назначение IP-адресов.

Протокол Reverse Address Resolution Protocol (RARP), впервые описанный в июне 1984 г. (RFC 903), используется компанией Sun Microsystems и рядом других производителей, в частности, для запуска бездисковых рабочих станций. Основной принцип его работы сводится к тому, что клиент должен самостоятельно отыскать свой IP-адрес, а не принять адрес, выделенный сервером. Сравнительно недавно появился динамический вариант этого протокола (Dynamic RARP, DRARP), реализующий алгоритм автоматического присвоения IP-адресов. Стоит отметить, что изначальный вариант RARP не поддерживает передачу клиенту каких-либо параметров конфигурации (кроме IP-адреса), в том числе применяемых при маршрутизации. В результате один сервер RARP способен обслуживать только одну локальную сеть.

Упрощенный вариант FTP - протокол Trivial File Transfer Protocol (TFTP) - увидел свет около 20 лет назад, его вторая версия описана в документе RFC 783. Фактически TFTP предоставляет транспортный механизм для передачи с сервера загрузочного образа клиентской системы.

Протокол Internet Control Message Protocol (ICMP) сегодня также можно отнести к поколению ветеранов Всемирной сети. Он позволяет информировать компьютеры о наличии в сети дополнительных маршрутизаторов (имеется специальный механизм для обнаружения этих устройств), предусматривает специальные типы сообщений для передачи маски подсети и других служебных сведений.

Наконец, протокол Network Information Protocol (NIP) был разработан в конце 80-х гг. сотрудниками Массачусетского технологического института в качестве распределенного механизма для динамического присвоения IP-адресов в сетях Ethernet.

Отметим еще спецификации RFC 1122 и 1123, которые используются рядом протоколов (в том числе DHCP). Они содержат требования к процедуре изменения конфигурации компьютеров сети и, кроме того, предлагают сценарий первоначального конфигурирования бездисковых станций.

DHCP и VLAN: различий больше, чем сходств

Время от времени можно встретить утверждение о том, что протокол DHCP и технология виртуальных частных сетей (VLAN) нацелены на решение одной и той же проблемы: они должны обеспечить свободное перемещение клиентов в сетевой среде. В действительности за приведенными выше аббревиатурами скрываются две совершенно разные концепции, причем подход на базе виртуальных ЛС является гораздо более революционным.

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

Сетевое оборудование, наделенное средствами динамического формирования виртуальных ЛС, дает возможность так определить конфигурацию сети, что независимо от того, к какому порту концентратора или коммутатора будет подключена станция-клиент, она получит те же IP-адрес и имя и попадет в состав заранее описанной виртуальной локальной сети. Распределение же MAC-адресов по виртуальным ЛС может задаваться самой конфигурацией сети. Другой вариант предполагает, что IP-адреса распознаются по пакетам, которые поступают от станций-клиентов.

Итак, различия между протоколом DHCP и технологией VLAN можно суммировать следующим образом:

• DHCP изменяет конфигурацию перемещаемого компьютера, тогда как в сети с поддержкой VLAN изменение претерпевает сетевой порт, к которому подключается компьютер;
• динамическое изменение конфигурации средствами DHCP требует наличия DHCP-сервера, ретранслирующего агента в каждом маршрутизаторе и поддержки данного протокола клиентским ПО TCP/IP. В случае использования технологии виртуальных локальных сетей одна и та же схема VLAN должна поддерживаться всеми концентраторами (коммутаторами) сети, что открывает широкий простор для патентованных реализаций;
• DHCP позволяет сконфигурировать новую клиентскую станцию, а средства VLAN - нет;
• протокол DHCP служит прежде всего для обеспечения максимально динамичного конфигурирования сети, разделенной на подсети по территориальному признаку. Основное же назначение технологии VLAN состоит в объединении пользователей не по географическому, а по какому-либо иному, например функциональному, принципу (в соответствии с характером их деятельности или ролью в бизнесе компании).

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

3. Протокол клиент-сервер. Алгоритм работы DHCP

DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на рис. 1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY.

Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP.

Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения. Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения.

В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER".

3.1. Взаимодействие клиента и сервера при выделении сетевого адреса

Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис. 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.

Таблица 2: Сообщения DHCP

Рис. 3. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером в ходе присвоения нового сетевого адреса

Если выбранный сервер не может адекватно реагировать на сообщение DHCPREQUEST (например, запрошенный сетевой адрес уже выделен), сервер должен реагировать посылкой сообщения DHCPNAK.

Сервер должен пометить адрес, предложенный клиенту в сообщении DHCPOFFER, как доступный, если сервер не получил от клиента никакого сообщения DHCPREQUEST.

Клиент реализует таймаут и повторно посылает сообщение DHCPREQUEST, если клиент не получает ни сообщения DHCPACK ни DHCPNAK. Клиент повторно посылает DHCPREQUEST согласно алгоритму повторной пересылки, описанному в разделе 4.1. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго; например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно послать сообщение DHCPREQUEST четыре раза, при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент не получает ни сообщения DHCPACK ни DHCPNAK после применения алгоритма повторной пересылки, клиент возвращается в исходное состояние и перезапускает процесс инициализации. Клиент должен уведомить пользователя о том, что процесс инициализации не прошел и делается повторная попытка.

3.2. Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов

Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на рис. 4 показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.

Рис. .4. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером при повторном присвоении ранее использованного сетевого адреса

Если запрос клиента не корректен (например, клиент переместился в другую субсеть), серверы должны реагировать посылкой клиенту сообщения DHCPNAK. Серверы не должны откликаться, если их информация не абсолютно надежна. Например, сервер, который идентифицирует запрос для набора параметров, который принадлежит другому серверу, и имеет истекший срок действия, сервер не должен реагировать сообщением DHCPNAK, если только серверы не используют явно механизм поддержания когерентности.

Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент может не иметь правильного сетевого адреса или сетевой маски, и клиент может не отвечать на ARP-запрос. В противном случае, сервер должен послать сообщение DHCPNAK по IP-адресу транспортного агента BOOTP, записанного в 'giaddr'. Транспортный агент, в свою очередь, переадресует сообщение непосредственно по аппаратному адресу клиента, так что DHCPNAK будет доставлен, даже если клиент переместился в другую сеть.

Если клиент обнаруживает, что IP-адрес в сообщении DHCPACK уже использован, клиент должен послать сообщение DHCPDECLINE серверу и повторно запустить процесс конфигурации, послав запрос на новый сетевой адрес. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP, которая описана в разделе 4.4.

Если клиент получает сообщение DHCPNAK, он не может повторно использовать свой запомненный сетевой адрес. Он должен вместо этого запросить новый адрес путем повторного запуска конфигурационного процесса. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP.

Клиент выполняет таймаут и повторно посылает сообщение DHCPREQUEST. Если клиент не получает ни сообщения DHCPACK, ни DHCPNAK, клиент, согласно алгоритму из раздела 4.1, повторно посылает сообщение DHCPREQUEST. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго. Например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно передать сообщение DHCPREQUEST четыре раза при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент после повторной пересылки не получил ни сообщения DHCPACK, ни DHCPNAK, он может решить использовать присвоенный ранее сетевой адрес и конфигурационные параметры вплоть до истечения срока их действия. Это соответствует переходу в состояние BOUND на диаграмме состояний клиента, показанной на рис. 5.

Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE.

3.3. Интерпретация и представление значений времени

Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.

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

Алгоритм интерпретации времени действия конфигурационного набора, представленный в предыдущем параграфе, предполагает, что часы клиента и сервера стабильны относительно друг друга. Если имеется относительный дрейф этих часов, сервер может считать время действия конфигурационного набора исчерпанным, а клиент - нет. Чтобы компенсировать такого рода эффект, сервер может послать клиенту значение времени действия короче того, которое он записывает в свою базу данных.

3.4. Получение параметров при внешне заданных адресах

Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.

Сервер в целях совместимости должен проверить сетевой адрес в сообщении DHCPINFORM, но не должен проверять существующее значение времени действия конфигурационного набора. Сервер формирует сообщение DHCPACK, содержащее конфигурационные параметры для клиента, приславшего запрос, и посылает сообщение DHCPACK непосредственно клиенту.

3.5. Параметры клиента в DHCP

Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A. Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. Об этом говорит сайт https://intellect.icu . 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST.

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

Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'.

Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING.

Если сервер получает сообщение DHCPREQUEST с некорректным 'запрошенным IP-адресом', он должен прислать клиенту сообщение DHCPNAK и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.

3.6. Применение DHCP для клиентов с несколькими интерфейсами

Клиент с несколькими сетевыми интерфейсами должен использовать DHCP для получения конфигурационных параметров через каждый из интерфейсов независимо.

3.7. Когда клиентам следует использовать DHCP?

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

Если клиент знает предыдущий сетевой адрес и не может контактировать с локальным DHCP-сервером, клиент может продолжать использовать предыдущий сетевой адрес до тех пор, пока время действия адреса не истечет. Если время действия исчерпано до того, как клиент смог контактировать с DHCP-сервером, клиент должен немедленно прекратить использование текущего сетевого адреса и может проинформировать о данной проблеме локального пользователя.

Источники информации

Спецификация протокола DHCP описана в RFC 2131 и ряде вспомогательных документов, перечень и тексты которых можно найти в Internet по адресу http://www.ietf.org/html.charters/dhc-charter.html. Там же имеется обширный список предварительных спецификаций (Internet Drafts), регламентирующих различные аспекты работы данного протокола.

Документы RFC содержатся и на ряде других Web-серверов, например http://info.internet.isi.edu/ls/in-notes/rfc/; http://www.cis.ohio-state.edu/hypertext/information/rfc.html; http://www.pmg.lcs.mit.edu/rfc.html.

Подборка документов Internet Drafts по протоколу DHCP размещена на серверах ftp.bucknell.edu/pub/dhcp/и http://www.bucknell.edu/~droms/dhcp/.

Информация по протоколу DHCP, что называется, из первых рук, а также многие вспомогательные материалы доступны на сервере соответствующей рабочей группы: http://www.dhcp.org.

4 Использование автоматической адресации TCP/IP без DHCP-сервера (APIPA)

при инициализации компьютера на основе Windows (настроенного для DHCP) он выполняет вещание трех или более "discover" сообщений. если DHCP-сервер не отвечает после вещания нескольких сообщений discover, Windows компьютер назначает себе адрес класса B (APIPA). затем Windows компьютер отобразит сообщение об ошибке для пользователя компьютера (ему не назначен IP-адрес с сервера DHCP). после этого Windows компьютер будет отсылать сообщение Discover каждые три минуты при попытке установить связь с DHCP-сервером.

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

компьютер на основе Windows пытается повторно установить аренду IP-адреса. если Windows компьютер не находит сервер DCHP, он назначает себе IP-адрес после создания сообщения об ошибке. Затем компьютер передает четыре сообщения Discover и через каждые 5 минут повторяет всю процедуру до тех пор, пока DHCP-сервер не выйдет из системы. После этого создается сообщение о том, что обмен данными с DHCP-сервером был восстановлен.

Вау!! 😲 Ты еще не читал? Это зря!

• RARP
• BOOTP
• Zeroconf
• WINS
• DHCP relay
• OSI

В общем, мой друг ты одолел чтение этой статьи об dhcp. Работы впереди у тебя будет много. Смело пиши комментарии, развивайся и счастье окажется в твоих руках. Надеюсь, что теперь ты понял что такое dhcp, протокол динамической настройки узла, apipa и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Компьютерные сети