Кратко

  • У динамической аренды DHCPv4 три существенных рубежа: T1 переводит клиента в RENEWING и даёт первое слово выдавшему адрес серверу, T2 включает широковещательный REBINDING, а истечение срока прекращает право на адрес, если новый DHCPACK не получен.
  • Перепривязка повышает доступность, но не наделяет полномочиями любой достижимый сервер. Продлить аренду может только альтернативный сервер с локальной административной властью и согласованными сведениями о привязке.

Адрес ещё отвечал, когда круг решающих уже изменился

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

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

Поэтому привычное «аренда продлевается автоматически» слишком неточно. Важен не повтор запроса сам по себе, а последовательный переход от близости к первоначальному решению, через более широкое восстановление, к обязательному отказу.

Повторное использование адресов потребовало возвратной привязки

В октябре 1993 года RFC 1541 определил динамическое распределение DHCP как предоставление адреса на ограниченный период либо до явного освобождения. Связь клиента, IP-адреса и параметров конфигурации стала управляемой серверами привязкой.

Ограниченность позволила одному пулу последовательно обслуживать разных клиентов. Один и тот же адрес можно выдать снова лишь потому, что прежняя выдача не считается вечным владением.

RFC 2131, опубликованный в марте 1997 года, сохранил автоматическое, динамическое и ручное распределение. Автоматическое может быть постоянным, ручное переносит выбор администратора, а динамическое зависит от часов аренды и состояний повторного получения.

Таким образом, адрес выступает не отдельной вещью, которую однажды забирает клиент, а частью ограниченного во времени решения о конфигурации, поддерживаемого службой по местным правилам.

В одной аренде работали три таймера

RFC 2132 назначает параметр 51 сроку аренды адреса, 58 — времени продления T1, 59 — времени перепривязки T2. Все три значения являются интервалами в секундах от назначения адреса, а не календарными отметками.

Если сервер не передал допустимые T1 и T2, RFC 2131 использует половину и семь восьмых срока. Рекомендуется и небольшое случайное отклонение, чтобы множество клиентов не начало восстановление одновременно. Эти доли — запасные значения протокола, а не универсальная рекомендация для эксплуатации.

За порядком стоит политика. До T1 остаётся время для разговора с первоначальной стороной. После T2 сохраняется последняя возможность найти более широкий, но всё ещё законный ответ. Истечение — не ещё один порог повтора, а конец текущей привязки.

T1 сохранял первое слово за выдавшим адрес сервером

Достигнув T1, клиент из BOUND переходит в RENEWING. Если адрес выдавшего сервера известен, DHCPREQUEST отправляется ему, а текущий адрес помещается в ciaddr. Клиент не выбирает среди новых предложений, а просит продолжить прежнее решение.

Такое предпочтение сохраняет ответственность за состояние. Исходный сервер знает созданную им привязку, правила пула и изменения параметров, которые должны сопровождать продление. Он может ответить DHCPACK с новым сроком, изменить конфигурацию либо не продлить её по административным причинам.

Отсутствие немедленного ответа не отменяет действующий адрес. Пока старый срок не вышел, именно он разрешает использование; клиент ограниченно повторяет запрос, учитывая время до T2. Краткий сбой управления не обрывает передачу сразу, но часы продолжают идти.

T2 расширял слышимость запроса, а не власть каждого слушателя

Если DHCPACK не пришёл до T2, клиент переходит в REBINDING. Он передаёт DHCPREQUEST широковещательно, оставляет используемый адрес в ciaddr и не указывает идентификатор сервера. Запрос становится доступен машинам, до которых он раньше не доходил.

Однако услышать его — не значит получить право продлевать. RFC 2131 допускает продление другим сервером только при наличии у него локальных административных полномочий. Многосерверной площадке необходимы согласованное состояние аренд и операционное делегирование.

В этом смысл перепривязки. Ради доступности круг возможных ответчиков растёт, но сетевая достижимость не превращается в полномочие. Устаревший резервный сервер способен признать свободным ещё занятый адрес. Широковещательная передача обнаруживает расхождение, но не создаёт общего контроля.

ACK, NAK и тишина означали разные решения

DHCPACK в RENEWING или REBINDING устанавливает продолжение. Клиент сохраняет возвращённый срок и параметры, затем запускает новые T1 и T2. Поскольку конфигурация может измениться, продление не сводится к механическому сдвигу даты.

DHCPNAK — явное сообщение, что текущая конфигурация неприемлема. Клиент должен прекратить её использование и вернуться к инициализации. Продолжение после NAK превратило бы сохранённую память в адресную претензию против управляющей системы.

Тишина до истечения срока не равна ни ACK, ни NAK. Она оставляет старую аренду в силе и вызывает ограниченные повторы. Но если ACK так и не получен, RFC 2131 требует перейти в INIT, остановить остальную сетевую обработку и запросить конфигурацию как неинициализированный клиент.

Порт коммутатора может оставаться активным, соседи из кеша — отвечать, маршрутизатор — пересылать. Эти признаки подтверждают только работу локального пути. Они не предоставляют нового права на адрес.

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

Перезагрузившийся клиент может помнить прежний адрес и считать, что вернулся в ту же сеть. INIT-REBOOT позволяет попросить его снова, но не превращает память клиента в действующее разрешение.

Запрос идёт широковещательно: неизвестно, актуальны ли прежние сервер и сеть. Сервер может подтвердить адрес с помощью DHCPACK или отклонить DHCPNAK. Если связь установить нельзя, RFC 2131 разрешает прежнюю конфигурацию лишь на ещё не истёкшую часть исходной аренды.

Неизменность адреса после запуска становится проверенным исходом, а не предположением. Протокол ценит непрерывность, однако не выводит текущую власть из значения, сохранённого заинтересованной стороной.

FORCERENEW позволил серверу приблизить проверку

Изначально автомат состояний приводили в движение главным образом клиентские таймеры. Позднее RFC 3203 ввёл одноадресное сообщение FORCERENEW, чтобы сервер мог до T1 направить клиента в обычное состояние RENEW, например ради изменения конфигурации.

Само FORCERENEW новые параметры не устанавливает. Оно вызывает обычный DHCPREQUEST. Если адрес требуется отозвать, сервер отвечает на этот запрос DHCPNAK и возвращает клиента к поиску.

Поддельный сигнал мог бы неоднократно прерывать активные сеансы. Поэтому RFC 3203 требует аутентифицировать FORCERENEW по процедурам RFC 3118. Даже досрочная проверка должна иметь подтверждённый источник и проходить через контролируемый переход состояния.

Разрешение сервера не доказывало отсутствие конфликта на канале

Подлинный DHCPACK не может гарантировать, что другой узел локального сегмента не использует тот же адрес. Решение службы конфигурации и наблюдение на канале — разные виды свидетельств.

RFC 5227 требует, чтобы узел IPv4 проверил новый адрес до начала использования. Обнаружив конфликт, DHCP-клиент посылает DHCPDECLINE. План сервера сталкивается с противоположным локальным фактом и подлежит пересмотру.

Сила свидетельства аренды ограничена: управляемая служба назначила адрес клиенту на некоторый интервал. Она не удостоверяет личность пользователя, не доказывает юридическое владение, не гарантирует сквозную связность и не исключает дублирование.

Источники и границы свидетельств

Исторические и протокольные утверждения основаны на RFC 1541, RFC 2131, RFC 2132, RFC 3118, RFC 3203 и RFC 5227:

Они определяют контракт DHCPv4, но не подтверждают нынешние настройки, схему отказоустойчивости, правильность клиента или долю внедрения какого-либо названного продукта или сети. DHCPv6 — другой протокол. Значения T1 и T2 по умолчанию также не доказывают, что их передаёт каждый сервер и принимает каждый клиент.