Протокол динамического распределения адресов DHCP. Интернет-технология и ее применение для задач управления организацией
Министерство образования Российской Федерации Тольяттинский Государственный Университет Кафедра "Информатика и ВТ" Индивидуальное домашнее задание "Протокол динамического распределения адресов DHCP. Интернет-технология и ее применение для задач управления организацией" Выполнила: Проверил: г. о. Тольятти 2009 Содержание - 1. Протокол динамического распределения адресов DHCP
- 1.1 Постановка задачи
- 1.2 Цели
- 1.3 Краткий обзор протокола
- 1.4 Основные конфигурационные параметры
- 1.5 Динамическое выделение сетевых адресов
- 1.6 Протокол клиент-сервер
- 1.7 Взаимодействие клиента и сервера при выделении сетевого адреса
- 1.8 Параметры клиента в DHCP
- 2. Интернет-технология и ее применение для задач управления организацией
- 2.1 Internet/intranet - технологический базис новых методов управления
- 2.2 Фундамент сетевого взаимодействия
- 2.3 Возможности Internet для предприятия
- 2.4 Интранет и методы управления
- Литература
1. Протокол динамического распределения адресов DHCPПротокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, - 2132, - 2485, - 2563, - 2610, - 2855, - 2937, - 2939, - 3004, - 3011, - 3046, - 3942, - 4030, - 4039; [22], [23], [24] и [25]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов. Протокол DHCP используется, помимо загрузки бездисковых станций или Х-терминалов (BOOTP), сервис-провайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. DHCP построен по схеме клиент-сервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ. ЭВМ не должна действовать как DHCP-сервер, если только она специально не сконфигурирована системным администратором. IP-протокол требует установки многих параметров. Так как IP-протокол может быть использован самым разным сетевым оборудованием, значения этих параметров не могут быть угаданы заранее. Кроме того, схема распределенного присвоения адресов зависит от механизма выявления уже используемых адресов. DHCP поддерживает три механизма выделения IP-адресов. При "автоматическом выделении", DHCP присваивает клиенту постоянный IP-адрес. При "динамическом присвоении", DHCP присваивает клиенту IP-адрес на ограниченное время. При "ручном выделении", IP-адрес выделяется клиенту сетевым администратором, а DHCP используется просто для передачи адреса клиенту. 1.1 Постановка задачиПротокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов.1.2 ЦелиНиже предлагается список основных задач DHCP:1. DHCP представляет собой механизм, а не политику. DHCP должен управляться местными системными администраторами, путем задания желательных конфигурационных параметров.2. Клиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры.3. Сети не должны требовать ручной конфигурации для отдельных клиентов. В нормальных условиях, сетевой администратор не должен вводить какие-либо индивидуальные конфигурационные параметры клиента.4. DHCP не требует отдельного сервера для каждой субсети.5. Клиент DHCP должен быть готов получить несколько откликов на запрос конфигурационных параметров. Для повышения надежности и быстродействия можно использовать несколько 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'.
Страницы: 1, 2, 3
|
