1. Автоматизированная настройка TCP/IP
Настройка параметров TCP/IP для каждой станции в большой сети обычно сопряжена с тяжелой и долгой работой, особенно когда возникает необходимость в изменении таких параметров TCP/IP, как IP-адреса и маски подсетей. Изменения могут быть обусловлены кардинальной реструктуризацией сети или наличием в ней многочисленных мобильных пользователей с портативными компьютерами, которые могут подключаться к любому сегменту сети. Возможны как физические, так и беспроводные подключения. Поскольку параметры конфигурации TCP/IP компьютера зависят от того, к какому сегменту он подключен, переход компьютера в другой сегмент сети должен сопровождаться соответствующим изменением параметров.

Только компетентный сетевой администратор хорошо понимает все последствия, к которым приводит изменение параметров TCP/IP. Группа IETF разработала для объединенных сетей TCP/IP несколько протоколов автоматической настройки, в том числе ВООТР (Boot Protocol) и DHCP (Dynamic Host Configuration Protocol).

1.1 Динамическая настройка конфигурации с применением BOOTP
Протокол ВООТР проектировался для того, чтобы протоколы IP (Internet Protocol) и UDP (User Datagram Protocol) могли использоваться для передачи информации компьютерам, желающими настроить свою конфигурацию. Компьютер, сгенерировавший запрос, называется клиентом ВООТР, а компьютер, ответивший на запрос клиента, называется сервером ВООТР (рис.1 "Клиенты и серверы ВООТР").

Целью клиентского запроса ВООТР является получение значений параметров IP для компьютера, на котором работает клиент ВООТР.

Протокол ВООТР описан в RFC 951. Обновленная информация содержится в RFC 2132, RFC 1532, RFC 1542 и RFC 1395.

1.2 IP-адреса запросов/ответов ВООТР

Сообщения ВООТР инкапсулируются в заголовках UDP, идентифицирующих номер порта, используемого процессами ВООТР. Дейтаграмма UDP

инкапсулируется в заголовке IP. Но какие адреса отправителя и получателя используются в заголовке IP? Интересный вопрос, потому что при выдаче запроса клиент ВООТР должен указать эти адреса. Как правило, клиент ВООТР не знает своего IP-адреса и указывает вместо него 0.0.0.0. Если же адрес известен, он используется в клиентском запросе ВООТР.

Известен ли IP-адрес сервера клиенту ВООТР? В общем случае неизвестен.

Это особенно верно по отношению к ситуациям, когда клиент ВООТР представляет собой бездисковую рабочую станцию и не располагает средствами для определения адреса сервера. Впрочем, если адрес сервера ВООТР может настраиваться на уровне рабочей станции, он используется клиентом ВООР. Если клиент ВООТР не знает IP-адрес сервера ВООТР, он использует ограниченную рассылку IP. В качестве адреса ограниченной рассылки используется следующее значение: 255.255.255.255

Пакеты, отправленные по адресу ограниченной (локальной) рассылки, принимаются всеми IP-узлами локального сегмента сети, включая серверы ВООТР.

А если сервер ВООТР находится в другой подсети IP, за граничным маршрутизатором? Как говорилось выше, ограниченная рассылка за маршрутизатор не распространяется. Для таких случаев на маршрутизаторе работает агент-ретранслятор ВООТР (ВООТР relay agent), который проверяет, используется ли в дейтаграмме ограниченной рассылки приемный порт UDP с номером 67 (порт зарезервирован для BOOTP/DHCP). Если условие выполняется, ограниченная рассылка перенаправляется в сетевые интерфейсы маршрутизатора (рис.2 "Пересылка сообщений ВООТР через граничный маршрутизатор").

Сервер ВООТР, находящийся в локальной сети, может ответить на запрос клиента ВООТР. Будет ли в этом сообщении использоваться IP-адрес клиента?

Иначе говоря, может ли сервер ВООТР послать направленный ответ? Все зависит от реализации сервера ВООТР.

Сервер знает IP-адрес клиента, хранящийся в базе данных конфигурации ВООТР. Почему же он не может использовать этот адрес для посылки направленного ответа клиенту? Дело в том, что в момент отправки сервером запроса ARP на получение аппаратного адреса клиента ВООТР клиент ответить не может. Почему? Потому что он еще не знает своего IP-адреса. Сервер ВООТР получает аппаратный адрес клиента из заголовка канального уровня в сообщении клиента ВООТР. Реализация сервера ВООТР может добавить запись с информацией о клиенте ВООТР в кэш ARP (рис.3 "Изменение кэша ARP сервером ВООТР"). При наличии такой записи сервер ВООТР может использовать направленный ответ.

Модификация кэша ARP используется в реализации ВООТР для BSD Unix.

Если сервер ВООТР не изменяет содержимое кэша ARP, ответ рассылается в широковещательном режиме.

1.3 Потеря сообщений ВООТР
В своей работе ВООТР использует протоколы UDP и IP, не гарантирующие доставки сообщений. В результате возможна потеря, задержка, дублирование или нарушение последовательности сообщений ВООТР. Поскольку контрольная сумма IP обеспечивает проверку целостности только заголовка, но не поля данных, реализация ВООТР может потребовать активизации контрольной суммы UDP, защищающей от ошибок во всем сообщении ВООТР.

При отправке запросов клиент ВООТР устанавливает флаг запрета фрагментации (DF), чтобы упростить обработку ответов ВООТР, а также на случай нехватки памяти для сбора фрагментированных дейтаграмм.

Для борьбы с потерей сообщений в ВООТР используется механизм тайм-аута с повторной передачей. Отправляя запрос, клиент ВООТР запускает таймер.

Если ответ ВООТР будет получен до истечения интервала тайм-аута, отсчет прекращается; в противном случае ВООТР передает запрос заново.

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

1.4 Формат сообщения ВООТР
На рис.4 "Формат сообщения BOOT" изображена структура сообщения ВООТР. Отдельные поля сообщения описаны в табл.1 "Поля сообщений ВООТР".

Поле	Длина в октетах	Описание
ор	1	Тип сообщения: 1 - запрос (BOOTREQUEST), 2 - ответ (BOOTREPLY)
htype	1	Тип аппаратного адреса. Значения совпадают со значениями аналогичного поля в пакетах ARP. Например, код 1 соответствует сети Ethernet 10 Мбит/с
hlen	1	Длина аппаратного адреса в октетах. Аппаратные адреса Ethernet и Token Ring имеют длину 6 байт
hops	1	Поле обнуляется клиентом ВООТР. Может использоваться агентом-ретранслятором, работающим на маршрутизаторе, при пересылке сообщений ВООТР
xid	1	Код транзакции - случайное число, задаваемое клиентом ВООТР при построении сообщения. Сервер ВООТР использует код транзакции в своих ответах клиенту. Наличие кода xid позволяет клиентам и серверам ВООТР связать сообщение ВООТР с ответом
secs	1	Заполняется клиентом ВООТР. Содержит количество секунд, прошедших с начала загрузки клиента
-	2	Не используется
ciaddr	4	IP-адрес клиента ВООТР. Заполняется клиентом в сообщении BOOTREQUEST, предназначенном для проверки использования ранее назначенных параметров конфигурации. Если клиент не знает свой IP-адрес, полю присваивается 0
yiaddr	4	IP-адрес клиента ВООТР, возвращаемый сервером ВООТР
siaddr	4	IP-адрес сервера. Значение присваивается клиентом ВООТР, если клиент хочет связаться с конкретным сервером ВООТР. IP-адрес сервера ВООТР может храниться в конфигурационной базе данных TCP/IP на клиенте ВООТР. Сервер может вернуть адрес следующего сервера, с которым следует связаться в процессе загрузки, - например, адрес сервера, на котором хранится загрузочный образ операционной системы
giaddr	4	IP-адрес маршрутизатора, на котором работает агент-ретранслятор ВООТР
chaddr	16	Аппаратный адрес клиента ВООТР.16 октетов зарезервированы для того, чтобы данное поле позволяло представлять различные типы аппаратных адресов. В архитектурах Ethernet и Token Ring используются только 6 октетов
sname	64	Необязательное имя сервера (если оно известно клиенту ВООТР). Хранится в формате строки, завершенной нуль-символом
file	128	Имя загрузочного образа. Хранится в формате строки, завершенной нуль-символом. Если клиент ВООТР хочет загрузить образ операционной системы, принятый с сетевого устройства, он может задать обобщенное имя - например, "unix" для загрузки образа Unix На сервере ВООТР может храниться дополнительная информация о конкретной операционной системе, необходимой для этой рабочей станции. Ответ, полученный от сервера ВООТР, содержит полностью определенное имя файла
vendor	64	Дополнительные данные, смысл которых определяется поставщиком. Например, при запросе в этом поле может передаваться тип/серийный номер устройства, а при ответе - информация о поддержке некоторых возможностей или идентификатор удаленной файловой системы. Информация может быть зарезервирована для использования ядром или загрузчиком третьей фазы

1.5 Фазы ВООТР
Несмотря на свое название, протокол ВООТР не используется для фактической пересылки образа операционной системы клиенту ВООТР. Пересылка образа осуществляется отдельным протоколом TFTP (Trivial File Transfer Protocol), который использует в качестве транспорта протокол UDP. Бездисковые рабочие станции загружают образ операционной системы с сервера; другие станции просто используют ВООТР для централизованного назначения IP-адресов, без загрузки системы.

На рис.5 "Пример работы bootstrap" изображены фазы, из которых состоит процесс загрузки образа операционной системы. На шаге 1 клиент ВООТР выдает запрос на получение данных конфигурации IP. На шаге 2 сервер ВООТР возвращает данные конфигурации IP и имя загружаемого файла с образом операционной системы. На шаге 3 клиент ВООТР посылает запрос на загрузку образа операционной системы клиенту TFTP. На шаге 4 клиент TFTP посылает серверу TFTP запрос на загрузку образа операционной системы. На шаге 5 сервер TFTP возвращает серию пакетов данных, содержащих образ операционной системы. После принятия образа ВООТР загружает его в память и инициализируется.

Отделение ВООТР от механизма пересылки образа операционной системы обладает тем преимуществом, что сервер ВООТР не обязан работать на том компьютере, на котором хранятся образы операционных систем (то есть сервере TFTP). Кроме того, это позволяет использовать ВООТР в ситуациях, когда с сервера принимаются только данные конфигурации, без пересылки образа операционной системы.

Возможна ситуация, в которой администратор настраивает рабочую станцию на загрузку разных операционных систем в зависимости от пользователя. В этом случае запрос ВООТР может содержать в поле имени файла обобщенное обозначение - например, "unix" для принятия образа операционной системы Unix, или "default" для загрузки образа операционной системы по умолчанию.

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

1.6 Дополнительные данные

В формате сообщения ВООТР явно заданы стандартные параметры IP. Многие поставщики оборудования передают своим устройствам дополнительные параметры. Для таких случаев в сообщения ВООТР было включено поле дополнительных данных.

В поле vendor сообщения ВООТР клиенту передаются данные, интерпретация которых определяется поставщиком оборудования. Поле не является обязательным, а его применение зависит от того, какая дополнительная информация нужна клиенту ВООТР. Первые четыре октета содержат "волшебное число" - признак формата остальных полей. Эти четыре октета задаются в десятичной записи с точечным разделением (не путайте их с IP-адресами!). Скажем, произвольно выбранная последовательность 99.130.83.99 (в шестнадцатеричной записи - 63.82.53.63) является общепринятым обозначением стандартного формата области дополнительных данных. За признаком формата перечисляются элементы, каждый из которых характеризуется следующими атрибутами:

метка (1 октет)

длина следующего поля данных (1 октет)

данные (переменная длина)

Метки элементов ВООТР описаны в RFC 1497, "ВООТР Vendor Information

Extensions". С появлением протокола DHCP дополнительные данные ВООТР и поле параметров DHCP были приведены к общему формату, описанному в RFC 2132, "DHCP Options and BOOTP Vendor Extensions". Некоторые часто используемые значения меток приведены в табл.2 "Стандартные метки дополнительных данных ВООТР".

Метка	Длина данных	Интерпретация
0	-	Используется только в целях выравнивания, чтобы следующие поля начинались с границы слова
1	4	Маска подсети
2	4	Смещение географической зоны, в которой находится подсеть клиента, от стандартного времени UTC (Coordinated Universal Time). Смещение выражается 32-разрядным целым числом со знаком
3	N	Список IP-адресов маршрутизаторов в подсети клиента. Маршрутизаторы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
4	N	Маска подсети
5	N	Список серверов имен (IEN 116), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
6	N	Список серверов DNS (STD 13, EFC 1035), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
7	N	Список журнальных серверов (MIT-LCS UDP), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
8	N	Список серверов cookie (RFC 865), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
9	N	Список серверов построчной печати LPR (RFC 1179), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
10	N	Список серверов Imagen Impress, доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
11	N	Список серверов местонахождения ресурсов (RFC 887), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4
12	N	Имя хоста, соответствующее данному клиенту, с возможным уточнением имени локального домена. Допустимые символы описаны в RFC 1035. Минимальная длина поля данных равна 1 октету
13	N	Размер загрузочного файла. Определяет длину загрузочного образа, используемого клиентом по умолчанию, в 512-килобайтных блоках. Длина файла задается 16-разрядным целым числом без знака
128-254	Не определена	Интерпретация зависит от реализации
255	-	Признак конца информации в поле дополнительных параметров. Дальнейшие октеты должны быть заполнены нулями

2. Динамическая настройка (DHCP)
Протокол DHCP (Dynamic Host Configuration Protocol) является расширением протокола ВООТР и обладает более гибкими возможностями управления IP-адресами. DHCP может использоваться для динамической настройки основных параметров TCP/IP хостов (рабочих станций и серверов), работающих в сети.

Протокол DHCP состоит из двух компонентов:

механизм назначения IP-адресов и других параметров TCP/IP

протокол согласования и передачи информации о хостах Хост, запрашивающий данные о конфигурации TCP/IP, называется клиентом DHCP, а хост TCP/IP, предоставляющий эту информацию, называется сервером DHCP. Протокол DHCP описан в RFC 2131, "Dynamic Host Configuration Protocol".

2.1 Распределение IP-адресов в DHCP
В DHCP используются три способа назначения IP-адресов:

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

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

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

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

Метод динамического назначения адресов особенно удобен для клиентов DHCP, нуждающихся в IP-адресе для временного подключения к сети. Для примера рассмотрим сеть класса С, к которой могут подключаться до 300 мобильных пользователей с портативными компьютерами. Сеть класса С может содержать до 253 узлов B55 - 2 специальных адреса = 253). Поскольку компьютеры, подключающиеся к сети через TCP/IP, должны обладать уникальными IP-адресами, все 300 компьютеров не могут подключиться к сети одновременно. Тем не менее, если в любой момент времени в сети возможно не более 200 физических подключений, появляется возможность переназначения неиспользуемых адресов класса С за счет применения механизма динамического назначения адресов DHCP.

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

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

2.2 Назначение IP-адресов в DHCP
Обратившись с запросом к серверу DHCP, клиент DHCP проходит ряд внутренних стадий, во время которых он согласовывает с сервером срок и область использования IP-адреса. Процесс получения IP-адреса клиентом DHCP лучше всего объяснить на диаграмме переходов (то есть конечного автомата). На Рис.6 "Диаграмма переходов для протокола DHCP, поясняющая процесс взаимодействия между клиентом и сервером" изображена диаграмма, поясняющая процесс взаимодействия между клиентом и сервером DHCP.

При первом запуске клиент DHCP находится в состоянии ИНИЦИАЛИЗАЦИЯ. На этой стадии клиент DHCP еще не знает своих параметров IP, поэтому он рассылает запрос DHCPDISCOVER, инкапсулированный в пакете UDP/IP. В пакете указан приемный порт UDP 67 (десят) - такой же, как у сервера ВООТР, потому что протокол DHCP является расширением ВООТР. В пакете DHCPDISCOVER используется адрес локальной рассылки 255.255.255.255. Если серверы DHCP находятся за пределами локального сегмента, на маршрутизаторе IP должен работать агент-ретранслятор, который перешлет запрос DHCPDISCOVER в другие подсети. Поддержка агентов-ретрансляторов DHCP рассматривается в RFC 1542.

Прежде чем рассылать запрос DHCPDISCOVER, клиент DHCP выдерживает паузу случайной продолжительности от 1 до 10 секунд. Это делается для того, чтобы предотвратить одновременное начало работы клиентов DHCP при их одновременном включении (как иногда происходит после сбоя питания).

После рассылки запроса DHCPDISCOVER клиент DHCP входит в состояние ВЫБОР. В этом состоянии клиент DHCP получает сообщения DHCPOFFER от серверов DHCP, настроенных для ответа этому клиенту. Период времени, в течение которого клиент DHCP ожидает сообщения DHCPOFFER, зависит от реализации. Если клиент получает сразу несколько ответов DHCPOFFER, он должен выбрать один из них. Выбрав сообщение DHCPOFFER от одного из серверов, клиент DHCP посылает этому серверу сообщение DHCPREQUEST. Сервер DHCP отвечает сообщением DHCPACK.

Дополнительно клиент DHCP может проверить IP-адрес, переданный в сообщении DHCPACK, и убедиться в том, что этот адрес не используется. В сетях с широковещательной рассылкой клиент DHCP может отправить по указанному адресу запрос ARP и проверить наличие ответа ARP. Получение ответа ARP означает, что предложенный IP-адрес уже используется; в этом случае ответ DHCPACK от сервера игнорируется, отправляется ответ DHCPDECLINE, а клиент DHCP переходит в исходное состояние ИНИЦИАЛИЗАЦИЯ и пытается получить свободный IP-адрес. При рассылке запроса ARP в локальной сети клиент указывает в пакете ARP собственный аппаратный адрес в поле аппаратного адреса отправителя, но в поле IP-адреса отправителя заносится нулевое значение. Нулевой IP-адрес используется вместо предложенного IP-адреса, чтобы избежать возможной путаницы с кэшами ARP других хостов TCP/IP (в том случае, если предложенный IP-адрес уже используется).

Когда клиент получает от сервера DHCP сообщение DHCPACK, он определяет три временных интервала и переходит в состояние ПРИВЯЗКА. Первый интервал Т1 определяет срок возобновления аренды; второй интервал Т2 определяет срок повторной привязки; третий интервал ТЗ определяет продолжительность аренды.

С сообщением DHCPACK всегда возвращается значение ТЗ, то есть продолжительность аренды. Значения Т1 и Т2 настраиваются на сервере DHCP, а если они не были заданы, используются значения по умолчанию, основанные на продолжительности срока аренды, рассчитанные по следующим формулам:

Т1 = интервал возобновления Т2 = интервал повторной привязки ТЗ = продолжительность аренды Т1 = 0,5 х ТЗ

Т2 = 0,875 х ТЗ

Моменты времени, в которые происходит тайм-аут, вычисляются прибавлением интервала ко времени отправки сообщения DHCPREQUEST, по которому было сгенерировано подтверждение DHCPACK.

Если запрос DHCP был отправлен в момент ТО, то моменты тайм-аута по всем трем интервалам вычисляются по следующим формулам:

тайм-аут по Т1 = ТО + Т1

тайм-аут по Т2 - ТО + Т2

тайм-аут по ТЗ в ТО + ТЗ

В RFC 2131 рекомендуется увеличивать Т1 и Т2 на величину случайной задержки, чтобы предотвратить одновременное наступление тайм-аута на нескольких клиентах DHCP.

При истечении интервала Т1 клиент DHCP переходит из состояния ПРИВЯЗКА в состояние ВОЗОБНОВЛЕНИЕ. В этом состоянии клиент DHCP должен согласовать с сервером DHCP, выдавшим исходный IP-адрес, новый срок аренды для назначенного IP-адреса. Если исходный сервер DHCP отказывается возобновить аренду, он посылает сообщение DHCPNAK; клиент возвращается в состояние ИНИЦИАЛИЗАЦИЯ и пытается получить новый IP-адрес. Если исходный сервер DHCP отправляет сообщение DHCPACK, в этом сообщении указывается новая продолжительность аренды. Клиент DHCP снова устанавливает интервалы Tl, T2 и ТЗ и переходит в состояние ПРИВЯЗКА.

Если интервал Т2 истекает в тот момент, когда клиент DHCP в состоянии ВОЗОБНОВЛЕНИЕ ожидает сообщения DHCPACK или DHCPNAK от исходного сервера DHCP, клиент переходит из состояния ВОЗОБНОВЛЕНИЕ в состояние ПОВТОРНОЕ СВЯЗЫВАНИЕ. Исходный сервер DHCP может не ответить из-за того, что он временно недоступен или из-за сбоя в сетевом канале. Из приведенных выше формул видно, что Т2 > Т1, поэтому клиент DHCP дополнительно ждет возобновления аренды в течение времени Т2-Т1.

При истечении интервала Т2 в сети рассылается широковещательный запрос DHCPREQUEST для всех серверов DHCP, способных возобновить аренду; клиент DHCP находится в состояние ПОВТОРНОЕ СВЯЗЫВАНИЕ. Рассылка запроса объясняется тем, что после ожидания Т2-Т1 секунд в состоянии ВОЗОБНОВЛЕНИЕ клиент DHCP приходит к выходу, что исходный сервер DHCP недоступен, и пытается связаться с любым сервером DHCP, способным ему ответить. Если сервер DHCP отвечает сообщением DHCPACK, клиент DHCP возобновляет аренду (ТЗ), задает интервалы Т1 и Т2 и переходит в состояние ПРИВЯЗКА. Если ни один сервер DHCP не сможет возобновить аренду до истечения интервала ТЗ, аренда становится недействительной и клиент DHCP переходит в состояние ИНИЦИАЛИЗАЦИЯ. Обратите внимание: к этому моменту клиент DHCP уже дважды пытался возобновить аренду - сначала с исходного сервера DHCP, а затем с любого сервера DHCP в сети.

При истечении срока аренды (ТЗ) клиент DHCP должен прекратить использование IP-адреса и все сетевые операции с этим IP-адресом.

Чтобы прекратить использование IP-адреса, клиент DHCP не обязан дожидаться истечения срока аренды (ТЗ). Он может намеренно отказаться от использования IP-адреса, отменив аренду. Предположим, пользователь с портативным компьютером подключился к сети для выполнения некоторой операции. Сервер DHCP в сети предоставил ему IP-адрес сроком на один час. Пользователь закончил свою работу за 30 минут и теперь хочет отключиться от сети. В процессе корректного отключения компьютера клиент DHCP посылает серверу сообщение DHCPRELEASE, чтобы сервер отменил аренду досрочно. Возвращенный IP-адрес в дальнейшем может использоваться другим клиентом.

Если клиент DHCP работает на компьютере, оснащенном жестким диском, то IP-адрес может храниться на этом диске и при запуске компьютера клиент может запросить использовавшийся ранее адрес. На рис.8.6 этой ситуации соответствует состояние "ПЕРЕЗАГРУЗКА с известным IP-адресом".

2.3 Формат сообщения DHCP
Структура сообщения DHCP изображена на рис.7 "Формат пакета DHCP". В сообщениях DHCP все поля имеют фиксированный формат, кроме поля дополнительных данных, минимальный размер которого равен 312 октетам. Видно, что сообщения DHCP и ВООТР имеют почти одинаковый формат, не считая полей флагов и дополнительных параметров. Более того, сервер DHCP может быть настроен на обработку запросов ВООТР (процедура настройки зависит от операционной системы).

Отдельные поля сообщений протокола DHCP описаны в табл.3 "Поля сообщений DHCP". В поле флагов используется только крайний левый бит (рис.8 "Формат пакета DHCP"), остальные биты должны быть равны нулю.

Поле	Длина в октетах	Описание
ор	1	Тип сообщения: 1 - запрос (BOOTREQUEST), 2 - ответ (BOOTREPLY)
htype	1	Тип аппаратного адреса. Значения совпадают со значениями аналогичного поля в пакетах ARP. Например, код 1 соответствует сети Ethernet 10 Мбит/с
hlen	1	Длина аппаратного адреса в октетах. Аппаратные адреса Ethernet и Token Ring имеют длину 6 байт
hops	1	Поле обнуляется клиентом DHCP. Может использоваться агентом-ретранслятором, работающим на маршрутизаторе, при пересылке сообщений DHCP
xid	1	Код транзакции - случайное число, задаваемое клиентом DHCP при построении сообщения. Сервер DHCP использует код транзакции в своих ответах клиенту. Наличие кода xid позволяет клиентам и серверам DHCP связать сообщение DHCP с ответом
seсs	1	Заполняется клиентом DHCP. Содержит количество секунд, прошедших с начала загрузки клиента
flags	2	Если крайний левый бит равен 1, сообщение является широковещательным. Все остальные биты должны быть равны 0
ciaddr	4	IP-адрес клиента DHCP. Заполняется клиентом в сообщении DHCPREQUEST, предназначенном для проверки использования ранее назначенных параметров конфигурации. Если клиент не знает свой IP-адрес, полю присваивается 0
yiaddr	4	IP-адрес клиента DHCP, возвращаемый сервером DHCP
siaddr	4	IP-адрес сервера. Значение присваивается клиентом DHCP, если клиент хочет связаться с конкретным сервером DHCP. IP-адрес сервера DHCP может быть получен при помощи сообщений DHCPOFER и DHCPACK, ранее возвращенных сервером. Сервер может вернуть адрес следующего сервера, с которым следует связаться в процессе загрузки, - например, адрес сервера, на котором хранится загрузочный образ операционной системы
giaddr	4	IP-адрес маршрутизатора, на котором работает агент-рретранслятор DHCP
chaddr	16	Аппаратный адрес клиента DHCP.16 октетов зарезервированы для того, чтобы данное поле позволяло представлять различные типы аппаратных адресов. В архитектурах Ethernet и Token Ring используются только 6 октетов
sname	64	Необязательное имя сервера (если оно известно клиенту DHCP). Хранится в формате строки, завершенной нуль-символом
file	128	Имя загрузочного образа. Хранится в формате строки, завершенной нуль-символом. Если клиент DHCP хочет загрузить образ операционной системы, принятый с сетевого устройства, он может задать в DHCPDISCOVER обобщенное имя - например, "unix" для загрузки образа Unix. На сервере DHCP может храниться дополнительная информация о конкретной операционной системе, необходимой для этой рабочей станции. Ответ сервера DHCP может возвращаться в виде полностью определенного имени файла в сообщении DHCPOFFER
options	312	Дополнительные параметры

Большинство сообщений DHCP, передаваемых сервером DHCP клиенту, являются направленными (то есть посылаются на один конкретный IP-адрес). Это объясняется тем, что сервер DHCP узнает адрес клиента DHCP из сообщений, отправляемых клиентом серверу. Клиент DHCP может потребовать, чтобы сервер отвечал по адресу широковещательной рассылки, для чего крайний левый бит поля options устанавливается в 1. Клиент DHCP поступает подобным образом, если он еще не знает своего IP-адреса. Модуль IP на клиенте DHCP отвергает полученную дейтаграмму, если IP-адрес получателя, указанный в дейтаграмме, не совпадает с IP-адресом сетевого интерфейса клиента DHCP. Если IP-адрес сетевого интерфейса неизвестен, дейтаграмма также отвергается. С другой стороны, модуль IP принимает любые широковещательные дейтаграммы DHCP. Следовательно, чтобы модуль IP заведомо принимал ответ сервера DHCP, когда IP-адрес еще не настроен, клиент DHCP должен потребовать, чтобы сервер отправлял широковещательные сообщения вместо направленных.

Поле options имеет переменную длину. Его минимальный размер увеличен до 312 октетов, чтобы общий минимальный размер сообщения DHCP составлял 576 октетов - минимальный размер дейтаграммы IP, принимаемой хостом. Если клиент DHCP должен использовать сообщения большего размера, он согласовывает максимальный размер при помощи специального параметра. Поскольку поля sname и file довольно велики, но используются не всегда, область параметров можно расширить в эти поля при помощи параметра Option Overload. Если этот параметр присутствует, обычный смысл полей sname и field игнорируется и в этих полях ищутся параметры в формате TLV (Type, Length, Value).

Из рис.9 "Формат параметра в сообщениях DHCP" видно, что в DHCP параметр представляется полем типа A октет), за которым следует поле длины A октет). Значение поля длины определяет размер поля значения. Различные сообщения DHCP представляются специальным кодом типа 53. Значения параметров, определяющих сообщения DHCP, приведены на рис.10 "Значения параметров в сообщениях DHCP".

2.4 Трассировка протокола DHCP

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

Destination IP Address - IP-адрес получателя Source IP Address - IP-адрес отправителя Ethernet Header - заголовок Ethernet

UDP Header - заголовок UDP

UDP Source Port - UDP-порт отправителя UDP Destination Port - UDP-порт получателя Ethernet type - тип Ethernet

Рис.10 "Значения параметров в сообщениях DHCP"

Протокол DHCP и формат его пакетов являются расширениями ВООТР. Клиенты и серверы DHCP используют те же номера портов, что и клиенты и серверы ВООТР, то есть клиенты DHCP использует порт UDP с номером 68, а серверы DHCP - порт UDP с номером 67. Большинство анализаторов протоколов расшифровывает сообщения DHCP и BOOT в одном формате.

Заключение Протоколы ВООТР и DHCP решают важную проблему автоматической настройки параметров IP (в частности, IP-адресов и масок подсети) для отдельных сетевых устройств. Оба протокола основаны на архитектуре "клиент-сервер" и используют одинаковые номера портов UDP. Протокол DHCP проектировался в качестве замены старого протокола ВООТР, а его сообщения представляют собой расширение формата сообщений ВООТР.

Главное преимущество DHCP заключается в том, что этот протокол позволяет арендовать IP-адреса на временной основе. Тем самым обеспечивается более гибкое управление IP-адресами в ситуациях, когда IP-адреса не обязаны жестко ассоциироваться с конкретным компьютером по аппаратному адресу. Механизм назначения IP-адресов в ВООТР менее гибок, поскольку IP-адрес связывается с аппаратным адресом сетевого интерфейса.

Литература

1. G. Stump, R. Droms, Y. Gu, R., Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. The User Class Option for DHCP, RFC-3004, November 2000.

2. M. Patrick, DHCP Relay Agent Information Option. RFC-3046, January 2001.

3. S. Alexander, DHCP Options and BOOTP Vendor Extensions, RFC-2132

5. http://www.dhcp-handbook.com/dhcp_faq.html

6. http://ru. wikipedia.org/wiki/DHCP

7. http://kunegin. narod.ru/nata/tcpip_prof. pdf

8. http://www.bog. pp.ru/work/bootp.html