1.3 Краткий обзор протокола

С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента. В RFC-1542 [2] детализировано взаимодействие между BOOTP - и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4). На рис.1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах. Существует два принципиальных отличия между DHCP и BOOTP. Во-первых, DHCP определяет механизмы, через которые клиентам на определенное время могут быть присвоены сетевые адреса, позволяя последовательное присвоение сетевого адреса различным клиентам. Во-вторых, DHCP предоставляет механизм, который позволяет клиенту получить все необходимые им для работы конфигурационные параметры. DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".

Рис.1. Формат сообщения DHCP

DHCP определяет новую опцию client identifier, которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля chaddr в сообщениях BOOTP, где chaddr используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле chaddr, или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле siaddr как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле siaddr, если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции server identifier. Назначения полей заголовка представлены в таблице 1.

Таблица 1. Описание полей сообщения DHCP

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

В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента TCP/IP полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения TCP/IP в вольной интерпретации RFC-1122. Программа TCP/IP должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом. Для того чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа TCP/IP, DHCP использует поле флаги [21]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На рис.2 показан формат поля флаги.

Рис.2: Формат поля флаги

B: флаг BROADCAST MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)