Кратко

  • draft-ietf-intarea-dhcp-rate-signaling-00 разрешает DHCP snooping-коммутатору использовать rate option для локального shaper, policer или очереди, превращая телеметрического наблюдателя в участника управления.
  • Доказательная цепочка должна соединять байты пакета, доверенный вход, сессию, адресата, тип rate, локальный предел, commit конфигурации и считанное состояние аппаратуры с последующим результатом.

Термин snooping обещает пассивность. Коммутатор смотрит DHCP, связывает адрес с портом, помогает фильтровать поддельные ответы. Но новый rate option дает наблюдению иной исход: увиденное значение может стать аппаратной очередью или полисером. Пакеты абонента после этого идут иначе.

Предложение INTAREA несет скорости upstream и downstream и тип расчета на уровне 2 или 3. Оно предназначено для сетей, где физический Ethernet быстрее купленного доступа: CPE, relay или коммутатор могут поместить shaping и AQM ближе к реальному узкому месту.

Revision 00 опубликована 27 августа 2026 как Informational Internet-Draft и истекает 28 февраля 2027. Это не RFC, не обязательство внедрения и не перепись реальных сетей. Запрошенные коды опций еще проходят стандартный процесс.

Перехват поля не доказывает мандат

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

Для исполнительного действия нужен полный receipt: trust domain входного порта, связь с абонентской сессией, transaction ID, состояние DHCP, уровень инкапсуляции, направление, rate type, целевой интерфейс, физическая способность порта, локальный cap, команда конфигурации и read-back аппаратуры.

Если switch установил 400 Mbit/s, увидев поле для CPE, число могло быть синтаксически верным и все же предназначаться не ему. Правильные данные у неправильного исполнителя образуют неверную политику.

Relay способен изменить основание до точки наблюдения

В DHCPv4 relay может прочитать option из DHCPACK, настроить собственный shaper и добавить, изменить или удалить поле перед пересылкой — например, после получения атрибутов RADIUS или другого AAA.

Значение на выходе сервера и входе клиента становится двумя доказательствами. Законная мутация все равно требует истории: relay, session binding, версия AAA, старое и новое число, причина, тип, направление, адресат и срок.

RFC 3046 описывает relay-agent information, RFC 2865 — RADIUS. Но ссылка на стандарт не подтверждает право конкретного узла переписать конкретную сессию. Если snooping-коммутатор видит лишь конечное поле, ему нужна внешняя проверяемая связь с этой историей.

В DHCPv6 вложенность задает получателя

Сервер может послать одну скорость клиенту в REPLY, а другие — relay-узлам в слоях RELAY-REPL. CPE может получить 480 Mbit/s, а access relay — 520 Mbit/s для допуска burst. Разница осмысленна, потому что адресаты различны.

Relay обязан брать option из собственного заголовка и не искать удобное число внутри клиентской нагрузки. Контроль над внешним контейнером не дает полномочий на все внутренние инструкции.

Коммутатору тем более нельзя считать каждое увиденное поле командой себе. Лог должен сохранять слой вложенности и target, а не только subscriber и rate.

OFFER влияет на выбор, ACK разрешает действие

Клиент может учитывать значение из DHCPOFFER или ADVERTISE, выбирая сервер. Применять его к интерфейсу разрешается лишь после DHCPACK или REPLY. Ранний сигнал участвует в выборе источника власти, но сам еще не дает власти изменить очередь.

Запись «получено 500 Mbit/s» скрывает решающий переход. Подтвердил ли выбранный сервер число? Было ли оно переписано? Сохраняется ли lease? Один и тот же набор цифр меняет статус по ходу протокола.

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

Parser тоже принимает управленческое решение

Layer-2 и Layer-3 rate различаются границей учета. Ошибка типа может сдвинуть узкое место. Неизвестные suboption codes разрешено игнорировать ради расширяемости, но неизвестное значение в понятом и существенном поле, например rate type, делает всю Rate Option недействительной.

Повторяющиеся поля обрабатываются по порядку, используется последнее. Нормализация в неупорядоченное множество стирает решение. DHCP lease при этом способен успешно установиться, хотя rate policy отвергнута. Успех адресации и успех ограничения — разные результаты.

Одинаковое число может сменить источник

При конфликте DHCPv4 и DHCPv6 проект отдает предпочтение v6 и требует хранить source protocol вместе с примененным rate. Если оба дают 500 Mbit/s, после истечения v6 lease экран не изменится, но полномочие перейдет к v4.

Меняются сервер, relay path и срок. Без действующего v4 lease устройство возвращается к default. В PPPoE DHCP rate приоритетнее значения из PPP authentication reply, но завершение сессии отзывает его.

Ноль означает unrestricted либо удаление прежнего limiter. Это не измеренная нулевая емкость. Смешение команды и метрики превращает корректный сброс в ложную аварию.

Незащищенная команда может безупречно сработать

DHCP часто передается открыто и без аутентификации. Rogue server или on-path attacker способен внедрить низкое значение. IP-связность остается зеленой, а полезный сервис деградирует.

Минимальный sanity threshold отбрасывает часть крайностей, физический cap ограничивает завышенные значения. Ни то ни другое не аутентифицирует источник. RFC 3118 описывает DHCP authentication, однако существование RFC не доказывает deployment. Нужна проверка trusted ports, server allow-list, relay validation, snooping protections, session binding и полномочий AAA.

Подход Heng Lu о running-code primacy здесь требует смотреть на реальное состояние, изменяющее пакеты. Но исполняемость не равна легитимности: вместе с read-back должен сохраняться приказ, который создал это состояние.

Очередь — действие, не итог

Точная скорость узкого места полезна для shaping и AQM. RFC 7567 объясняет вред переполненных очередей, RFC 9330 — использование малых очередей в L4S. Установка queue не доказывает меньшую задержку.

После commit нужны фактическая конфигурация, occupancy, marks, drops, распределение latency, throughput, ошибки и rollback. Option receipt подтверждает намерение; hardware receipt — действие; пользовательский эффект требует отдельного наблюдения.

Надежная общая спецификация остается тонкой: направление, тип учета, target, допустимое состояние сообщения, срок, приоритет источников и fallback. Она не делает subscriber profile истинным, relay прозрачным или результат хорошим самим фактом кодирования числа.

Неопределенность

Проект может измениться, быть заменен или истечь. Здесь не подтверждена реализация конкретным оператором, CPE, relay, switch или firmware. Заявленные выгоды производительности и поддержки остаются гипотезами для проверки в каждой сети.

Источники