Кратко

  • Опция 121 в RFC 3442 позволила DHCPv4 передавать маршруты с явно указанной длиной префикса, устранив классовое предположение прежней опции статических маршрутов.
  • Поддерживающий её клиент должен был установить эти маршруты и предпочесть их значениям Router и опции 33, если все они пришли вместе. RFC отдельно предупреждал: неверный следующий переход может увести трафик не туда.

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

Изменение устраняло несоответствие. Опция 33 DHCP из RFC 2132 описывала статические маршруты без отдельной маски для каждого назначения. За этим стояло предположение, что границу сети можно вывести из класса адреса. Бесклассовая маршрутизация уже отказалась от такой логики: 10.0.0.0/8 и 10.0.0.0/24 — разные назначения, хотя их начало совпадает. Клиенту нужна длина префикса, чтобы понять, какие биты определяют маршрут.

Опция 121 компактно кодировала эту область. Дескриптор назначения начинался с длины префикса и содержал лишь значимые октеты адреса; за ним следовал четырёхоктетный адрес маршрутизатора. Перед установкой маршрута клиент восстанавливал адрес назначения и обнулял биты за пределами маски. RFC 3442 не превращал DHCP в протокол маршрутизации и не распространял таблицу маршрутов Интернета. Он позволил администратору использовать уже существующий сервер настройки узлов для установки выбранных статических маршрутов на клиентах.

Так важное решение перешло между административными уровнями. Таблица маршрутизации осталась на узле, и клиент по-прежнему сам обрабатывал настройки. Но теперь маршрут мог появиться из конфигурации DHCP-сервера, а не из локального редактирования каждого устройства. Клиент, поддерживавший опцию 121, должен был установить маршруты, кроме оговорённого случая локальной подсети. Если вместе с 121 приходили прежняя Router или опция 33, клиент обязан был их игнорировать. Имел значение и порядок запроса: в списке параметров опция 121 должна была стоять раньше Router и опции 33.

Совместимость была частью дизайна. Клиенты без поддержки 121 должны были игнорировать её. Поэтому RFC 3442 рекомендовал администраторам отправлять также Router, дублируя сведения о маршрутизаторе по умолчанию для старых клиентов. Это была стратегия перехода, а не доказательство того, какая доля устройств поддерживала новую опцию и как быстро происходило внедрение. Стандарт задаёт приоритет, но не может заставить каждый клиент его реализовать.

У этого механизма были и последствия для безопасности. RFC 3442 прямо предупреждал, что неверный адрес маршрутизатора может вызвать отказ в обслуживании или направить трафик через наблюдателя. Риск не был уникальным для опции 121: Router и прежняя опция маршрутов тоже могли указать неправильный следующий переход. Сама опция не доказывает, что маршрут разрешён, верен или безопасен. Аутентификация сообщений DHCP, если она используется, — отдельный механизм; подтверждение отправителя само по себе не делает выбор маршрута обоснованным.

На передачу влиял и размер пакета. Длинный список маршрутов мог не поместиться в традиционное сообщение DHCP, поэтому RFC 3442 рассматривал согласование большего размера сообщений и требовал поддержку сцепления длинных опций. Для общего канала с несколькими IP-подсетями в нём также описан специальный следующий переход 0.0.0.0, обозначающий напрямую доступную локальную подсеть. Клиенты без соответствующей функции в сетевом стеке должны были игнорировать такую запись.

Исторический шаг RFC 3442 был скромным, но показательным: когда маршрутизация стала бесклассовой, настройка адресов тоже должна была выражать область маршрута. Аренда превратилась в возможный носитель локальной политики пересылки. Клиент оставался местом установки маршрута, но администратор DHCP становился участником его выбора — с последствиями для следующего перехода, выходящими за рамки назначения адреса.

Источники