Контрольная работа: Протокол динамического распределения адресов DHCP. Интернет-технология и ее применение для задач управления организацией
6. DHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную.
7. DHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [21].
8. DHCP должен обслуживать существующих клиентов BOOTP.
DHCP должен:
1. Гарантировать, что любой специфический сетевой адрес не будет использоваться более чем одним клиентом DHCP одновременно.
2. Поддерживать DHCP конфигурацию клиента при стартовой перезагрузке DHCP-клиента. Клиенту DHCP должен, при каждом запросе по мере возможности, присваиваться один и тот же набор конфигурационных параметров (например, сетевой адрес).
3. Поддерживать конфигурацию DHCP-клиента при перезагрузке сервера, и, по мере возможности, DHCP-клиенту должен присваиваться один и тот же набор конфигурационных параметров.
4. Позволяет автоматически присваивать конфигурационные параметры новым клиентам, чтобы избежать ручной конфигурации.
5. Поддерживать фиксированное или постоянное присвоение конфигурационных параметров для заданного клиента.
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
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| op (1) | htype (1) | hlen (1) | Шаги (1) | ||||||||||||||||||||||||||||
| xid (4) | |||||||||||||||||||||||||||||||
| secs (2) | Флаги (2) | ||||||||||||||||||||||||||||||
| ciaddr (4) | |||||||||||||||||||||||||||||||
| yiaddr (4) | |||||||||||||||||||||||||||||||
| siaddr (4) | |||||||||||||||||||||||||||||||
| giaddr (4) | |||||||||||||||||||||||||||||||
| chaddr (16) | |||||||||||||||||||||||||||||||
| sname (64) | |||||||||||||||||||||||||||||||
| Файл (128) | |||||||||||||||||||||||||||||||
| Опции (длина переменная) | |||||||||||||||||||||||||||||||
DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.
Таблица 1. Описание полей сообщения DHCP
| Поле | Байт | Описание |
| op | 1 | Код операции сообщения / тип сообщения. |
| 1 | = BOOTREQUEST, 2 = BOOTREPLY | |
| htype | 1 | Тип аппаратного адреса, смотри раздел ARP в RFC "Assigned Numbers"; например, '1' для 10 мегабитного Ethernet. |
| Hlen | 1 | Длина аппаратного адреса (например, '6' для 10 мегабитного Ethernet). |
| Шаги | 1 | Клиент устанавливает это поле равным нулю, поле используется опционно агентами транспортировки, когда загрузка осуществляется через посредника. |
| Xid | 4 | ID-транзакции, случайное число, выбираемое клиентом, и используемое как клиентом, так и сервером для установления соответствия между запросами и откликами. |
| Secs | 2 | Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса. |
| Флаги | 2 | Флаги (смотри рис.2). |
| Ciaddr | 4 | IP-адрес клиента заполняется только в случае, если клиент находится в состоянии BOUND, RENEW или REBINDING и может реагировать на запросы ARP. |
| Yiadd | 4 | IP-адрес следующего сервера, используемого в процессе загрузки; присылается сервером в DHCPOFFER, DHCPACK. |
| Giaddr | 4 | IP-адрес агента транспортировки, используется когда загрузка осуществляется через посредника. |
| Chaddr | 16 | Аппаратный адрес клиента. |
| Sname | 64 | Опционное имя ЭВМ-сервера, строка завершается нулем. |
| Файл | 128 | Имя файла загрузки (Boot-файла), строка завершается нулем; имя "generic" или нуль в DHCPDISCOVER, полное описание прохода в DHCPOFFER. |
| Опции | var | Поле опционных параметров. |
Поле опции имеет переменную длину. Клиент 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 показан формат поля флаги.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| B | MBZ | ||||||||||||||
Рис.2: Формат поля 'флаги'
B: флаг BROADCAST MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)
1.4 Основные конфигурационные параметры
Первым видом сервиса, предоставляемого DHCP, является запоминание сетевых параметров для клиента. Модель DHCP памяти характеризуется записями ключ - значение для каждого клиента, где ключ представляет собой некоторый уникальный идентификатор (например, номер IP-субсети и уникальный идентификатор в пределах субсети), а значение содержит набор конфигурационного параметров клиента. Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не предлагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.
1.5 Динамическое выделение сетевых адресов
Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает. Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе.
Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать. При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло.
Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно.
1.6 Протокол клиент-сервер
DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на рис.1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY.
Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP.
Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения. Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения. В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER".
1.7 Взаимодействие клиента и сервера при выделении сетевого адреса
Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис.3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены.
1. Клиент широковещательно пересылает сообщение DHCPDISCOVER по локальной физической субсети. Сообщение DHCPDISCOVER может включать опции, которые предлагают значения для сетевого адреса и длительности его использования. Агент транспортировки BOOTP может передать сообщение DHCP-серверам, которые размещены за пределами данной физической субсети.
2. Каждый сервер может откликнуться сообщением DHCPOFFER, которое содержит сетевой адрес в поле 'yiaddr' (и другие конфигурационные параметры в опциях DHCP). Серверы не должны резервировать предлагаемый сетевой адрес, хотя протокол будет работать более эффективно, если сервер избегает присвоения предлагаемого сетевого адреса другому клиенту. При выделении нового адреса, серверы должны проверять, чтобы предлагаемый сетевой адрес не использовался где-то еще; например, сервер может протестировать предлагаемый адрес с помощью эхо-запроса ICMP. Серверы должны быть реализованы так, чтобы сетевые администраторы могли выбрать желательные тесты для вновь выделяемых адресов. Сервер отправляет клиенту сообщение DHCPOFFER, используя, если необходимо транспортные средства BOOTP.
Таблица 2: Сообщения DHCP
| Сообщение | Использование |
| DHCPDISCOVER | Клиент посылает сообщение широковещательно, чтобы обнаружить доступный сервер. |
| DHCPOFFER | Посылается сервером клиенту в ответ на сообщение DHCPDISCOVER и содержит предложение по конфигурационным параметрам. |
| DHCPREQUEST | Сообщение клиента серверу либо (a) запрашивающее параметры от одного сервера и неявно отвергающее предложения других серверов, (b) подтверждающее корректность ранее присвоенного адреса после, например, перезагрузки системы, или (c) запрос расширения времени жизни конкретного сетевого адреса. |
| DHCPACK | Посылается сервером клиенту и содержит конфигурационные параметры, включая присвоенный сетевой адрес. |
| DHCPNAK | Посылается сервером клиенту, сообщая о том, что сетевой адрес не корректен (например, клиент переместился в новую субсеть), или время использования адреса клиентом истекло |
| DHCPDECLINE | Клиент и сервер обнаружили, что сетевой адрес уже используется. |
| DHCPRELEASE | Посылается клиентом серверу с целью отказа от сетевого адреса и аннулирует оставшееся время действия адреса. |
| DHCPINFORM | Посылается клиентом серверу с просьбой о локальных конфигурационных параметрах; клиент уже имеет полученный извне сетевой адрес. |
