Интегрированные сети ISDN
Спецификация протокола DHCP для системы клиент-сервер
4. Спецификация протокола DHCP для системы клиент-сервер
В этом разделе, мы предполагаем, что DHCP-сервер имеет блок сетевых адресов, из которого он может удовлетворять запросы. Каждый сервер поддерживает базу данных присвоенных адресов и времен их действия.
4.1. Формирование и посылка сообщений DHCP
Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей в секции сообщения с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4-октетную секцию 'magic cookie' (которая описана в разделе 3), за которой следуют собственно опции. Последняя опция должна быть всегда опцией 'end'.
DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера (67), а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента (68). Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может использовать для передачи исходящего DHCP-сообщения любой из своих сетевых адресов.
Поле 'server identifier' используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве 'server identifier', который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле 'giaddr' в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве 'server identifier'. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве 'server identifier' выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора).
DHCP-клиенты должны использовать IP-адрес, переданный через опцию 'server identifier', для любого уникастного запроса, адресованного DHCP-серверу.
Сообщения DHCP посылаются клиентом широковещательно, до тех пор пока он не получит свой IP-адрес, адрес поля отправителя в IP-заголовке при этом должно быть равно нулю.
Если поле 'giaddr' в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт 'DHCP server' агента транспортировки BOOTP, чей адрес указан в 'giaddr'. Если поле 'giaddr' равно нулю, а поле 'ciaddr' не равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле 'ciaddr'. Если 'giaddr' равно нулю и 'ciaddr' равно нулю, а бит broadcast =1, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =1 и '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' могла быть воспринята. Поле 'файл' должно интерпретироваться следующим (если опция 'option overload' указывает, что поле 'файл' содержит опции DHCP), за ним должно следовать поле 'sname'.
Значения, передаваемые в метку 'option' могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции 'router' [21]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров для конфигурации.
Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети 10Mбит/c 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.
4.2. Административное управление сервером 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 вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений 'vendor class identifier'.
4.3. Поведение сервера DHCP
DHCP-сервер обрабатывает приходящие от клиента DHCP-сообщения на основе текущего состояния набора конфигурирующих параметров клиента. DHCP-сервер может получать от клиента следующие сообщения:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера.
4.3.1. Сообщение DHCPDISCOVER
Когда сервер получает от клиента сообщение DHCPDISCOVER, он выбирает сетевой адрес для клиента, приславшего запрос. Если нет свободного адреса, сервер может проинформировать о проблеме системного администратора. Если адрес доступен, новый адрес должен быть выбран следующим образом:
| o | Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случае |
| o | Предшествующий адрес клиента, как это записано в текущем блоке параметров клиента (срок действия которого истек или использование которого прекратилось), если этот адрес находится в пуле доступных адресов сервера, в противном случае |
| o | Адрес запрошенный в опции 'Запрошенный IP-адрес', если адрес корректен и еще не присвоен, в противном случае |
| o | Новый адрес, полученный из пула свободных адресов; адрес выбирается с учетом субсети, откуда получено сообщение (если 'giaddr' = 0) или с учетом адреса агента транспортировки, который доставил сообщение (когда 'giaddr' не равен 0). |
Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.
Если это не требуется для корректной работы DHCP, сервер не должен повторно использовать выбранный сетевой адрес, прежде чем клиент пришлет сообщение серверу DHCPOFFER. Сервер может решить записать этот адрес, как предложенный клиенту.
Он должен также выбрать время действия конфигурационного набора, согласно следующим правилам:
| o | Если клиент не запросил специальный конфигурационный набор в сообщении DHCPDISCOVER и клиент уже имеет сетевой адрес, сервер присылает значение времени действия, ранее присвоенное данному адресу (заметим, что клиент должен явно запросить установления времени действия набора, чтобы переписать значение, ассоциированное с данным адресом), в противном случае |
| o | Если клиент не запросил определенное значение времени действия конфигурационного набора в сообщении DHCPDISCOVER и клиент не имеет сетевого адреса, сервер присваивает времени действия набора местное значение по умолчанию, в противном случае |
| o | Если клиент запросил специальный конфигурационный набор параметров в сообщении DHCPDISCOVER (вне зависимости оттого, имел ли он уже сетевой адрес), сервер может либо предоставить запрошенный набор (если это согласуется с местной политикой) или выбрать другой набор. |
