Кратко

  • RFC 3011 позволила запросить адрес в подсети, отличной от сети, через которую сообщение достигло DHCP-сервера; наблюдаемый источник и место расходования адресного ресурса стали разными фактами.
  • Идентичная опция 118 в ответе подтверждала узкий этап обработки, но не личность и полномочия клиента, не маршрут, отсутствие конфликта или фактическую услугу.

Обычный DHCP-сервер выбирал пул по следу, который уже оставила сеть. В RFC 2131 заполненное поле giaddr указывало на подсеть клиента за ретранслятором. Если поле было нулевым, сервер ориентировался на локальный интерфейс приёма. В типичной схеме место появления пакета и место выдачи адреса совпадали.

Устройство удалённого доступа нарушало это совпадение. С DHCP-сервером оно связывалось по внутренней сети, а адреса раздавало пользователям во внешних сетях. Между внутренней и внешней сторонами могло не быть обычной IP-связности. Запрос неизбежно приходил изнутри, хотя адрес следовало взять снаружи.

Опубликованная в ноябре 2000 года RFC 3011 задала общий формат такого расхождения. IPv4 Subnet Selection Option содержит четырёхоктетный адрес подсети: берётся адрес в целевой сети, а биты узла обнуляются маской. В действующем реестре параметров BOOTP/DHCP IANA это опция 118 длиной четыре.

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

Тем самым реальное место входа не объявлялось ложным. Оно продолжало описывать транспортный путь. Но пакет нёс отдельное указание о поверхности выделения. Локальная политика сервера решала, имеет ли отправитель право заменить наблюдение этим указанием.

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

В RFC был предусмотрен небольшой механизм совместимости. Сервер с включённой поддержкой обязан был вернуть точную копию опции, даже если клиент не перечислял её в Parameter Request List. Клиент, использующий механизм, должен был отбросить DHCPOFFER или DHCPACK без опции.

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

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

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

Поэтому функция должна была быть выключена по умолчанию и включаться явно. Серверу рекомендовалось ограничивать её конкретными client-id, сетями-источниками или списком разрешённых целевых подсетей. Стандарт определил, как выразить выбор, но не предоставил каждому отправителю право командовать ресурсом.

RFC 2132 дала грамматику «код — длина — значение». RFC 3011 присвоила коду 118 общую семантику. Возможность разобрать поле и обязанность ему подчиниться остались разными уровнями.

Более поздние документы переместили родственное утверждение к ретранслятору, контролируемому оператором. RFC 3046 определила Relay Agent Information с локальными идентификаторами линии и удалённой стороны. RFC 3527 добавила Link Selection для случая, когда сеть выделения отличается от адреса связи сервера с ретранслятором.

Если в пакете присутствовали и клиентская опция 118, и ретрансляторская Link Selection, последняя управляла выделением. Приоритет отражал не форму данных, а положение говорящего в модели доверия: оператор мог привязать управляемый ретранслятор к политике иначе, чем произвольного клиента.

Даже в таком случае простое появление подобной подопции в ответе не всегда доказывало понимание, потому что контейнер Relay Agent Information мог копироваться. RFC 3527 требовала административно обеспечить совместимость. RFC 3118 описала аутентификацию DHCP, но публикация механизма не доказывает его внедрения.

RFC 7969 позднее систематизировала настройку DHCP по топологии. Subnet Selection, Link Selection и Virtual Subnet Selection решают разные задачи. Точка входа, физический канал, логическая сеть, VPN, пул и обратный адрес больше не помещались в одно понятие местоположения.

Поэтому проверяемая запись хранит отдельно входной интерфейс, источник, giaddr, client-id, опцию 118, решение политики, выбранный пул, предложенный адрес, эхо и адрес ответа. Затем отдельно фиксируются lease, маршрут, соседство, абонентская сессия и результат приложения.

В логике Lu Heng о первичности работающего кода RFC 3011 была минимальной общей спецификацией. Она меняла один вход решения при локальном разрешении и не создавала глобальную власть над адресами. Общий номер обеспечивал совместимость; конфигурация и исполняемая политика показывали, кто действительно мог влиять на выдачу.

Запрос пришёл по внутренней сети. Адрес был взят из внешнего пула. Ответ вернулся по доступной точке. RFC 3011 сохранила все три утверждения и перестала выдавать один топологический след за доказательство остальных.

Sources