RFC-2131. Протокол динамической настройки сетевых устройств (компьютеров) (DHCPv4). Март 1997 года (категория: стандарт)

Подождите немного. Документ загружается.

ным требованием является то, чтобы время счётчика Т1 заканчивалось раньше

чем время счётчика Т2, которое, в свою очередь, должно заканчиваться раньше,

чем завершиться аренда адреса клиентом. Чтобы избежать необходимости син-

хронизации часов, показания счётчиков указываются в субполях дополнитель-

ных параметров как относительные значения времени.

В момент времени Т1 клиент переходит в

состояние “Обновления” (“Re-

newing”) и передаёт серверу в однонаправленном режиме DHCPREQUEST-

сообщение для продления своего срока аренды. Клиент вписывает в поле “IP-

адрес клиента” (ciaddr) DHCPREQUEST-сообщения свой текущий сетевой ад-

рес. Клиент фиксирует локальное значение времени, когда было отправлено

DHCPREQUEST-сообщение, с целью вычисления срока окончания аренды.

Клиент обязан не указывать “Идентификатор сервера” в DHCPREQUEST-

сообщении.

Любое поступившее DHCPACK-сообщение, в котором значение в поле

“Идентификатор процедуры информационного обмена” (xid) не совпадает со

значением в аналогичном поле DHCPREQUEST-сообщения, уничтожается по-

умолчанию. Когда клиент получает DHCPACK-сообщение от сервера, то он

вычисляет время окончания срока аренды как сумму следующих двух значе-

ний: а) времени в момент отправки DHCPREQUEST-сообщения и б)

продолжи-

тельности аренды, изъятой из принятого DHCPACK-сообщения. Клиент, ус-

пешно обновивший свой сетевой адрес, переходит в состояние “Готовности к

настройке” (“Bound”) и может продолжить работу в сети.

Если DHCPACK-сообщение не поступило до значения времени Т2, то

клиент переходит в состояние “Полной смены параметров настройки” (“Rebind-

ing”) и передаёт серверу в широковещательном режиме DHCPREQUEST-

сообщение

для продления своего срока аренды. Клиент вписывает в поле “IP-

адрес клиента” (ciaddr) DHCPREQUEST-сообщения свой текущий сетевой ад-

рес. Клиент обязан не указывать “Идентификатор сервера” в DHCPREQUEST-

сообщении.

Значения времени Т1 и Т2 устанавливаются сервером с помощью допол-

нительных параметров. Параметр Т1, по-умолчанию, составляет половину сро-

ка действия аренды:

T1 = 0.5 × duration_of_lease .

А параметр Т2, по-умолчанию, составляет 0,875 срока действия аренды:

T2 = 0.875 × duration_of_lease .

Значения времени Т1 и Т2 рекомендуется выбирать случайным образом в бли-

жайшей окрестности некоторого фиксированного целого числа (“some random

“fuzz” around a fixed value”), что позволит предотвратить синхронизм процедур

повторного назначения сетевого адреса клиента.

Клиент может завершить или продлить аренду до наступления времени

Т1. Сервер может продлить срок аренды клиентом сетевого адреса в соответст-

вие со стратегией сетевого управления, определённой сетевым администрато-

ром. Серверу рекомендуется указывать в ответных сообщения значения време-

ни Т1 и Т2, а сами эти значения должны быть установлены исходя из реальных

значений времени, учитывающих оставшееся время срока аренды.

Находясь в состояниях “Обновления” (“Renewing”) и “Полной смены па-

раметров настройки” (“Rebinding”), если клиент не получил ответных сообще-

ний на своё DHCPREQUEST-сообщение, то ему целесообразно “сделать паузу”,

равную половине оставшегося времени до наступления момента времени Т2 (в

состоянии “Обновления”) или равную половине оставшегося времени срока

аренды (в состоянии “Полной смены параметров настройки”), вплоть до мини-

мального значения, равного 60 секундам, перед началом повторной передачи

DHCPREQUEST-сообщения.

Если срок аренды истёк до того, как клиент получил DHCPACK-

сообщение, то клиент переходит в состояние “Начало” (Init) и обязан сразу же

остановить свою работу в сети и запросить сеть о начале установки

сетевых па-

раметров, как если бы он вообще не был настроен. Если клиент затем всё-таки

получает DHCPACK-сообщение, которое назначает клиенту ранее арендуемый

им адрес, то он должен продолжить работу в сети. Если клиент получил новый

сетевой адрес, то он обязан прекратить использование предшествующего сете-

вого адреса и должен оповестить

локальный пользователей о возникшей про-

блеме.

§4.4.6. Использование DHCPRELEASE-сообщения

Если клиент не желает больше использовать назначенный ему сетевой

адрес (например, клиент корректно выключается), он передаёт DHCPRE-

LEASE-сообщение серверу. (

Замечание. Корректное функционирование DHCP-

протокола не зависит от передачи DHCPRELEASE-сообщений.)

V. ВОПРОСЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

DHCP-протокол разработан для непосредственного встраивания в UDP- и

IP-протоколы, которые всё ещё являются не защищёнными. Более того, DHCP-

протокол главным образом предназначен для более простого обслуживания

удалённых и/или бездисковых сетевых устройств (компьютеров). Несмотря на

то, что возможно нет ничего невозможного, настройка таких сетевых устройств

с использованием паролей или криптоключей может

быть весьма трудной и не-

удобной. Следовательно, DHCP-протокол в сегодняшней его форме является

совершенно незащищённым.

Неавторизованные DHCP-серверы могут быть весьма легко установлены

и настроены. После этого, они могут транслировать ложную и потенциально

разрушительную информацию клиентам, например, некорректные или повто-

ряющиеся IP-адреса, некорректную маршрутную информацию (включая навя-

зывание ложной информации маршрутизаторам и т.п.), некорректные адреса

DNS-серверов (навязывание ложной информации DNS-серверам) и так далее.

Очевидно, что

если такая информация когда-нибудь появится в системе, то в

последующем нарушитель сможет скомпрометировать всю эту “зараженную”

систему и даже несколько связанных с ней систем.

Вредоносные DHCP-клиенты могут провести атаку типа “маскарад”, вы-

ступая в роли легитимных клиентов и перехватывая информацию, предназна-

ченную для таких легитимных пользователей. Там где используется динамиче

ский способ распределения ресурсов, вредоносный DHCP-клиент может потре-

бовать, чтобы все ресурсы были выделены только ему, а это фактически приве-

дет к отказу в обслуживании легитимных клиентов.

ПРИЛОЖЕНИЕ: Параметры настройки сетевых устройств

Название параметра Описание Источник

Параметры IP уровня для каждого сетевого компьютера: -

Маршрутизатор или нет? вкл./выкл. §3.1 RFC-1122 и -1123

Нелокальный субъект маршрутизации вкл./выкл. §3.3.5 RFC-1122 и -1123

Стратегия настройки фильтров для

маршрутизации нелокальный субъект

перечень §3.3.5 RFC-1122 и -1123

Максимальный размер фрагментации целое число §3.3.2 RFC-1122 и -1123

Время жизни (TTL) по-умолчанию целое число §3.2.1.7 RFC-1122 и -1123

Максимальный размер пакета на маршруте

(PMTU)

целое число §6.6 RFC-1191

Таблица MTU (постраничная) перечень §7 RFC-1191

Параметры IP уровня для каждого интерфейса: -

IP-адрес адрес §3.3.1.6 RFC-1122 и -1123

Маска подсети адресная маска §3.3.1.6 RFC-1122 и -1123

MTU целое число §3.3.3 RFC-1122 и -1123

MTU для всех подсетей вкл./выкл. §3.3.3 RFC-1122 и -1123

Приемлемый широковещательный адрес 0x00000000/0xffffffff §3.3.6 RFC-1122 и -1123

Осуществлять поиск маски подсети вкл./выкл. §3.2.2.9 RFC-1122 и -1123

Поддерживать маску подсети вкл./выкл. §3.2.2.9 RFC-1122 и -1123

Осуществлять поиск маршрутизатора вкл./выкл. §5.1 RFC-1256

Адрес для запроса маршрутизатора адрес §5.1 RFC-1256

адрес маршрутизатора

адрес

Маршрутизаторы

по-умолчанию (список)

степень предпочтения

целое число

§3.3.1.6 RFC-1122 и -1123

получатель

ГВМ/подсеть/сеть

маска получателя

адресная маска

тип обслуживания

целое число

маршрутизатор на первом

ретрансляционном участке

адрес

игнорировать

перенаправление

вкл./выкл.

§3.3.1.2 RFC-1122 и -1123

PMTU

целое число

Статические

маршрутизаторы

(список)

Осуществлять поиск PMTU

вкл./выкл.

§6.6 RFC-1191

Параметры канального уровня для каждого интерфейса:

Применение концевиков кадров вкл./выкл. §2.3.1 RFC-1122 и -1123

Время тайм-аута для хранения в

кэш-памяти ARP-данных

целое число §2.3.2.1 RFC-1122 и -1123

Повторное обрамление Ethernet-кадров

(RFC-894/RFC-1042)

§2.3.3 RFC-1122 и -1123

Параметры транспортного (ТСР-) уровня для каждого сетевого компьютера:

Время жизни (TTL) целое число

§4.2.2.19 RFC-1122 и -

1123

Интервал поддержки соединения целое число

Поддерживаемый размер данных 0/1

§4.2.3.6 RFC-1122 и -1123