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

Основные конфигурационные параметры

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

Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип аппаратного адреса, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCPклиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно, изза выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не предлагает идентификатор в явном виде, используя опцию client identifier. Клиент может запросить DHCPсервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.

Динамическое выделение сетевых адресов

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

При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса изза отсутствия свободных адресов. При таких условиях механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве контроля совместимости сервер должен проверить повторно используемые адреса, прежде чем снова пускать их в оборот. Это может быть, например, контроль посредством ICMP эхозапроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP.

Протокол клиент-сервер

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

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

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

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

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

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

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

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

Клиент широковещательно рассылает по локальной субсети сообщение DHCPREQUEST. Сообщение включает в себя сетевой адрес клиента в опции requested IP-адрес. Раз клиент не получил свой сетевой адрес, он не должен заполнять поле ciaddr. Агенты транспортировки BOOTP передают сообщение DHCPсерверам за пределами данной субсети. Если клиент использует client identifier для получения своего адреса, клиент должен использовать тот же client identifier в сообщении DHCPREQUEST

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

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

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

Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент выполняет окончательную проверку параметров, и отмечает время действия конфигурации, специфицированное в сообщении DHCPACK. Значение времени действия неявно задается client identifier или chaddr и сетевым адресом. С этого момента клиент считается сконфигурированным

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

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

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

Клиент может решить отказаться от сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью идентификатора клиента или chaddr и сетевого адреса в сообщении DHCPRELEASE

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

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

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

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

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

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

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

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

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

Не все клиенты требуют инициализации всех параметров. Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту.

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

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

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

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

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

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

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

Спецификация протокола DHCP для системы клиент-сервер

В этом разделе предполагается, что 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.

Поведение сервера DHCP

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

В таблице 6.3 рассмотрено использование полей и опций в DHCP-сообщении сервера.

Сообщение DHCPDISCOVER

Когда сервер получает от клиента сообщение DHCPDISCOVER, он выбирает сетевой адрес для клиента, приславшего запрос. Если нет свободного адреса, сервер может проинформировать о проблеме системного администратора. Если адрес доступен, новый адрес должен быть выбран следующим образом:

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

Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в giaddr. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети giaddr. Сервер волен выбрать какуюто другую субсеть.

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

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

Сервер может прислать vendor class identifier (идентификатор класса поставщика), использованный для определения параметров в сообщении DHCPOFFER, чтобы помочь клиенту решить, какой выбрать DHCPOFFER. Сервер вводит поле xid из сообщения DHCPDISCOVER в поле xid сообщения DHCPOFFER и посылает клиенту, приславшему запрос, сообщение DHCPOFFER.

Сообщение DHCPREQUEST

Сообщение DHCPREQUEST может прийти от клиента, реагирующего на сообщение сервера DHCPOFFER, от клиента, верифицирующего ранее выделенный IP-адрес, или от клиента, расширяющего время действия конфигурационного набора. Если сообщение DHCPREQUEST содержит опцию server identifier, то это отклик на сообщение DHCPOFFER. В противном случае, сообщение является запросом верификации или расширения времени действия набора. Если клиент использует client identifier в сообщении DHCPREQUEST, он должен применять его во всех последующих сообщениях. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включить этот список во все последующие сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с полученными ранее в сообщении DHCPOFFER. Клиент должен использовать для конфигурации параметры из сообщения DHCPACK. Клиенты посылают сообщения DHCPREQUEST следующим образом.

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

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

Если DHCPREQUEST генерируется в состоянии RENEWING, то идентификатор сервера не должен быть заполнен, опция запрошенный IP-адрес не должна быть заполнена, в ciaddr должен быть записан IP-адрес клиента. В этой ситуации клиент полностью сконфигурирован и пытается расширить срок действия конфигурационного набора. Это сообщение будет послано по уникастному адресу, таким образом, в обмен не будет вовлечено никаких агентов транспортировки. Так как giaddr не заполнен, DHCP-сервер будет полагаться на значение ciaddr и использовать его при передаче данных клиенту.

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

Сообщение DHCPDECLINE

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

Сообщение DHCPRELEASE

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

Сообщение DHCPINFORM

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

Сообщения клиента

Таблица 6.4 характеризует различие между сообщениями клиента в различных состояниях.

Поведение клиента DHCP

На рис. 6.5 представлена диаграмма состояний для DHCP-клиента. Клиент может получить следующие сообщения от сервера:

Сообщение DHCPINFORM не показано на рис. 6.5. Клиент просто посылает DHCPINFORM и ждет сообщенияотклика DHCPACK. Раз клиент выбрал свои параметры, он завершил процесс конфигурации. Таблица 6.5 описывает использование полей и опций DHCP-сообщения клиента.

Инициализация и выделение сетевого адреса

Клиент начинает работу в состоянии INIT и формирует сообщение DHCPDISCOVER. Клиент должен ждать случайное время в интервале 110 секунд, чтобы десинхронизовать процессы при запуске DHCP. Клиент устанавливает ciaddr равным 0x00000000. Клиент может запросить специфические параметры путем включения опции parameter request list. Клиент может предложить сетевой адрес и/или время действия набора параметров путем включения опций запрошенный IP-адрес и IPaddress lease time (время аренды IP). Клиент должен включить свой аппаратный адрес в поле chaddr, если это необходимо для доставки DHCP-откликов. Клиент может включить уникальный идентификатор в опцию client identifier. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включать этот список во все последующие сообщения.

Клиент генерирует и записывает случайный идентификатор транзакции, вставляет этот идентификатор в поле xid. Клиент записывает свое локальное время для использования позднее при вычислении времени пригодности набора конфигурационных параметров. Клиент затем посылает широковещательно DHCPDISCOVER по локальному аппаратному адресу 0xffffffff, по широковещательному IP-адресу и UDP-порту DHCP-сервера.

Если xid приходящего сообщения DHCPOFFER не согласуется с xid последнего сообщения DHCPDISCOVER, сообщение DHCPOFFER должно игнорироваться. Любое приходящее сообщение DHCPACK также должно игнорироваться.

Клиент собирает сообщения DHCPOFFER за определенный период времени, выбирает одно сообщение DHCPOFFER из числа приходящих сообщений DHCPOFFER (например, первое сообщение DHCPOFFER или сообщение DHCPOFFER от сервера, используемого ранее) и извлекает адрес сервера из опции server identifier сообщения DHCPOFFER.

Если параметры приемлемы, клиент записывает адрес сервера, который предоставляет параметры из поля server identifier и посылает этот адрес в поле server identifier широковещательного сообщения DHCPREQUEST. Раз от сервера пришло сообщение DHCPACK, клиент инициализирован и переходит в состояние BOUND. Сообщение DHCPREQUEST содержит тот же xid, что и сообщение DHCPOFFER. Клиент записывает время истечения действия конфигурационного набора как сумму времени, когда был послан исходный запрос, и длительности действия конфигурационного набора из сообщения DHCPACK. Клиент должен выполнить проверку предложенного адреса, чтобы убедиться, что адрес не используется. Например, если он находится в сети, которая поддерживает ARP, клиент может послать запрос ARP для предложенного адреса. При посылке широковещательного ARPзапроса для предлагаемого адреса, клиент должен записать туда, как отправитель, свой аппаратный адрес и 0 в качестве IP-адреса отправителя, чтобы исключить конфликт с ARPкэшами в других ЭВМ той же субсети. Если оказалось, что сетевой адрес используется, клиент должен послать серверу сообщение DHCPDECLINE. Клиент должен широковещательно послать ARPотклик, чтобы уведомить о новом IP-адресе клиента и удалить устаревшие записи из ARPкэша ЭВМ, размещенных в той же субсети.

Инициализация при известном сетевом адресе

Клиент начинает работу в состоянии INITREBOOT и посылает сообщение DHCPREQUEST. Клиент должен вставить свой сетевой адрес в опцию requested IP-адрес сообщения DHCPREQUEST. Клиент может запросить специфические конфигурационные параметры, включив опцию parameter request list. Клиент генерирует и записывает случайный идентификатор транзакции и заносит этот идентификатор в поле xid. Клиент записывает свое локальное время для последующего использования при вычислении времени истечения пригодности конфигурационного набора параметров. Клиент не должен включать server identifier в сообщение DHCPREQUEST. Клиент затем широковещательно посылает DHCP-серверу сообщение DHCPREQUEST с использованием аппаратного широковещательного адреса и UDP-порта.

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

Инициализация при сетевом адресе, заданном извне

Клиент посылает сообщение DHCPINFORM и может запросить специфические конфигурационные параметры путем включения их в опцию parameter request list. Далее он генерирует и записывает случайный идентификатор транзакции и вводит его в поле xid. Клиент помещает свой сетевой адрес в поле ciaddr. Ему в этом случае не следует запрашивать параметры времени действия конфигурационного набора.

Клиент посылает уникастное сообщение DHCPINFORM DHCP-серверу, если он знает адрес сервера, в противном случае он посылает это сообщение широковещательно. Сообщения DHCPINFORM должны быть направлены DHCP-серверу через UDP-порт.

Раз от любого из серверов получено сообщение DHCPACK с полем xid, согласующимся с тем, что содержалось в сообщении клиента DHCPINFORM, клиент инициализирован.

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

Использование широковещательной и уникастной адресации

DHCP-клиент широковещательно посылает сообщения DHCPDISCOVER, DHCPREQUEST и DHCPINFORM, если только не знает адреса DHCP-сервера. Клиент посылает сообщения DHCPRELEASE серверу уникастно.

Когда DHCP-клиент знает адрес DHCP-сервера, в состоянии INIT или REBOOTING, клиент может использовать адрес, записанный в DHCPDISCOVER или DHCPREQUEST, а не широковещательный IP-адрес. Клиент может также воспользоваться уникастной адресацией при посылке сообщений DHCPINFORM известному DHCP-серверу. Если клиент не получает отклика на DHCP-сообщение, посланное по IP-адресу известного DHCP-сервера, клиент переходит на широковещательную адресацию.

Восстановление и истечение пригодности

Клиент поддерживает две временные переменные, T1 и T2, которые специфицируют времена, когда клиент пытается расширить время действия своего сетевого адреса. T1 равно времени, когда клиент попадает в состояние RENEWING и пытается контактировать с сервером, который предоставил клиенту сетевой адрес. T2 равно времени, когда клиент перешел в состояние REBINDING и пытается контактировать с каким-­то сервером. Значение T1 должно соответствовать времени раньше T2, которое в свою очередь, должно быть раньше, чем время, когда истекает период годности конфигурационного набора параметров.

Чтобы исключить необходимость синхронизации часов, T1 и T2 выражаются в опциях в относительных единицах [6.2].

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

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

Если не приходит никакого DHCPACK до T2, клиент переходит в состояние REBINDING и посылает широковещательно сообщение DHCPREQUEST с целью расширения времени действия конфигурационного набора. Клиент устанавливает поле ciaddr в DHCPREQUEST равным его текущему сетевому адресу. Клиент не должен включать server identifier в сообщение DHCPREQUEST.

Времена T1 и T2 конфигурируются сервером посредством опций. T1 по умолчанию равно ( 0.5 * duration_of_lease ). T2 по умолчанию равно ( 0.875 * duration_of_lease ). Чтобы исключить синхронизацию восстановления состояния клиентов, времена T1 и T2 должны быть выбраны с некоторым случайным разбросом относительно фиксированных значений.

Клиент может решить, обновить или продлить время действия конфигурационного набора вплоть до T1. Сервер может решить расширить длительность пригодности конфигурационного набора параметров в соответствии с политикой сетевого администратора.

Как в состоянии RENEWING, так и в REBINDING, если клиент не получает отклика на свое сообщение DHCPREQUEST, он должен ждать половину остающегося времени вплоть до T2 (в состоянии RENEWING) и половину остающегося времени действия конфигурационного набора (в состоянии REBINDING), как минимум 60 секунд, прежде чем осуществить повторную отправку сообщения DHCPREQUEST.

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

Сообщение DHCPRELEASE

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

6.1. Трансляция сетевых адресов (NAT)

Многие частные и корпоративные сети начинали формироваться изолировано, и IP-адреса сетевым объектам администраторами присваивались произвольно. Когда возникала проблема подключения сети к Интернет, число ЭВМ оказывалось значительным и надо было их все реконфигурировать, заменяя все IP-адреса. Для решения подобных проблем был разработан протокол NAT (Network Address Translation; см. RFC-2663, 2766. 3489, 3519 и 4008).

NAT позволяет группе оконечных станций использовать "нелегальные" IP-адреса и в то же время иметь полноценный доступ к Интернет.

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

Кроме того, наряду с протоколом DHCP, протокол NAT позволяет более экономно использовать адресное пространство IP.

Существует разные алгоритмы реализации NAT: статический и динамический. В последнем случае реальный IP адрес выделяется для машины лишь на время ее работы в сети.

Одной из версий NAT является PAT (Port Address Translation) или NATP (Network Address Port Translation). Этот метод преобразования адресов может использоваться для трансляции адресов коммутируемых соединений РРР в небольших сетях (SOHO). PAT позволяет использовать один IP-адрес в нескольких сеансах L4. Каждому соединению со стороны клиента ставится в соответствие комбинация IP-адреса и порта. Так, можно для одного и того же IP-адреса осуществить десятки и даже сотни соединений, распределив их между соответствующим числом клиентов локальной сети. Сервер NAT поддерживает таблицу, где каждому соединению с Интернет ставится в соответствие IP-адрес и номер порта. Это делается часто в оборудовании для асинхронных каналов РРР, где адреса присваиваются случайным образом при каждом подключении.

В протоколе РАТ один общий IP-адрес транслируется с собственным номером порта UDP/TCP для группы ЭВМ. При настройке NAT маршрутизатор конфигурируется по выходным и входным интерфейсам. Выходной интерфейс подключается к внешней сети Интернет через легальный IP-адрес. Внутренний интерфейс подключается к локальной сети, которая пользуется нелегальными адресами. Ниже в таблице приведен пример трансляции адресов для случая обращения к внешнему удаленному почтовому серверу с IP=193.125.31.3. Адреса 10.10.10.1 и 10.10.10.2 являются внутренними, адрес 194.85.31.1 – IP внешнего порта сервера NAT. Из этого примера видно, что одному легальному глобальному адресу 194.85.31.1 может соответствовать практически любое число внутренних адресов (таблица 6.5.1).

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

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

6.2. NetBIOS

Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, не зависящего от фирмы­-производителя. NetBIOS применяет в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-10012, 1088 и STD48).

Пакет NETBIOS (см. также ftp://ietf.org/internetdrafts/draftietfpppextnetbiosfcp08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в Netbios распределяются динамически. Netbios имеет собственную DNS, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *.

Приложения могут через Netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт 137, для службы дейтограмм — порт 138, а для сессий — порт 139.

Любая сессия начинается с Netbios-запроса, задания IP-адреса и определения TCP-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbiosприложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.

При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления соединения между объектами. Имена Netbios должны содержать в себе IP-адреса. Так, часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** — IP-адрес. Система Netbios имеет собственную систему команд ( call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, загрузка удаленной программы ) и примитивов для работы с дейтограммами (послать дейтограмму, послать дейтограмму широковещательно, получить дейтограмму, получить широковещательную дейтограмму). Все оконечные узлы Netbios делятся на три типа:

IP-адрес может ассоциироваться с одним из указанных типов. B узлы устанавливают связь со своим партнером посредством широковещательных запросов. P и Mузлы для этой цели используют Netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).

Разработана (1985 г) улучшенная версия протокола NETBIOS — NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows NT и Windows XP, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. Netbeui базируется на протоколе OSI LLC2, вводит стандарт на формат кадра Netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные сложности при работе в региональных сетях. По этой причине Netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.

Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F ), который, в свою очередь, базируется на протоколе PPP. Формат кадра протокола NBFCP показан на рис. 6.6.

Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 6.6). Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов.