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

Формирование и посылка сообщений DHCP

Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4октетную секцию magic cookie за которой следуют собственно опции. Последняя опция должна быть всегда опцией end.

DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера 67, а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента 68.

Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может применять для передачи исходящего DHCP-сообщения любой из своих сетевых адресов.

Поле server identifier используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве идентификатора сервера, который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле giaddr в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве идентификатора сервера. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве идентификатора выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора). DHCP-клиенты должны пользоваться IP-адресом, переданным через опцию идентификатор сервера, для любого уникастного запроса, адресованного DHCP-серверу.

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

Если поле giaddr в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт DHCP server агента транспортировки BOOTP, чей адрес указан в giaddr. Если поле giaddr равно нулю, а поле ciaddr не равно нулю, то сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле ciaddr. Если giaddr равно нулю и ciaddr равно нулю, а бит broadcast =1, то сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =0, а giaddr равно нулю и ciaddr равно нулю, то сервер посылает сообщения DHCPOFFER и DHCPACK по аппаратному адресу клиента и адресу yiaddr. Во всех случаях, когда giaddr равно нулю, сервер широковещательно посылает любое сообщение DHCPNAK по адресу 0xffffffff.

Если опции в DHCP-сообщении распространяются на поля sname и файл, в поле опции должна появиться опция option overload со значением 1, 2 или 3, как это специфицировано в RFC-1533. Если в поле опции присутствует опция option overload, опции в этом поле должны завершаться end и могут содержать одну или более опций pad (заполнитель). Опции в полях sname и файл (если их применение индицировано опцией options overload ) должны начинаться с первого октета поля, завершаться end, и за ними для заполнения пространства до конца поля должны следовать опции pad. Любая индивидуальная опция в полях опции, sname и файл должна полностью умещаться в поле. Опции в поле options должны интерпретироваться первыми. Поле файл должно интерпретироваться следующим (если опция option overload указывает, что поле файл содержит опции DHCP), за ним должно следовать поле sname.

Значения, передаваемые в метку option, могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции router [6.15]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров конфигурации.

Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети Ethernet задержка перед первой повторной посылкой должна быть случайным образом равномерно распределенной при среднем значении 4 секунды. Задержка следующей (второй) ретрансмиссии должна быть также случайной и составлять 8 секунд. Значения времени последовательных повторных передач должны при каждой последующей попытке удваиваться. Максимальное значение равно 64 секунд. Клиент может обеспечить для пользователя индикацию попыток повторной передачи.

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

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

Клиент, который не может получать уникастные IP-дейтограммы, пока его протокольная программа не сконфигурирована, должен установить бит BROADCAST=1 в поле флагов в любом сообщении DHCPDISCOVER или DHCPREQUEST, которые клиент посылает. Бит BROADCAST укажет, что DHCP-сервер и агент транспортировки BOOTP должны посылать клиенту сообщения широковещательно. Клиент, который может получать уникастные IP-дейтограммы, до того как его программа сконфигурирована, должен сделать бит BROADCAST равным 0.

Сервер или агент доставки, посылающие или передающие DHCP-сообщение непосредственно DHCP-клиенту (т.e., не агенту транспортировки, указанному в поле giaddr ), должны анализировать бит BROADCAST поля флаги. Если этот бит равен 1, DHCP-сообщение должно быть послано как широковещательное по адресу 0xffffffff. Если бит BROADCAST равен 0, сообщение должно быть послано по уникастному IP-адресу указанному в поле yiaddr. Если уникастная транспортировка невозможна, сообщение может быть послано по широковещательному адресу 0xffffffff.

Административное управление сервером DHCP

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

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

DHCP-сервер должен использовать некоторый уникальный идентификатор, для того чтобы установить соответствие между клиентом и его набором конфигурационных параметров. Клиент может решить выдать идентификатор с помощью опции client identifier. Если клиент предоставляет client identifier (идентификатор клиента), он должен применять его во всех последующих сообщениях, а сервер должен использовать этот идентификатор для распознавания клиента. Если клиент не предоставляет опцию client identifier, сервер должен для идентификации клиента использовать содержимое поля chaddr. Для клиента DHCP весьма важно пользоваться уникальным идентификатором в пределах субсети, к которой он подключен согласно опции client identifier. Применение chaddr в качестве уникального идентификатора клиента может вызвать непредсказуемые результаты, так как такой идентификатор может быть ассоциирован с аппаратным интерфейсом, который может быть передан новому кли енту. Чтобы избежать непредсказуемых изменений сетевого адреса клиента (изза переноса аппаратного интерфейса) некоторые узлы могут использовать в качестве идентификатора клиента серийный номер производителя. Сетевые узлы могут также применять в качестве идентификатора клиента его DNS-имя.

Клиенты вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений vendor class identifier.