Кратко

  • draft-ietf-intarea-dhcp-rate-signaling-00 предлагает 64-битные значения для входящего и исходящего направлений и Rate Type, различающий информационный режим, уровень 2 и уровень 3. Это утверждение о сервисной политике, а не мгновенное измерение ёмкости.
  • Клиент вправе подсказать значение, сервер отвечает, ретранслятор может вставить или заменить опцию. В DHCPv6 разные уровни ретрансляции могут получить разные числа. Само происхождение «из DHCP» не определяет единственного автора и исполнителя.
  • Для эксплуатационного вывода нужно сохранить происхождение и срок действия, прочитать фактическую конфигурацию после записи, установить активную очередь и измерить метки, потери, задержку и доставку. Предыдущий этап не выдаёт квитанцию за следующий.

Домашний шлюз продлевает DHCPv6 и получает в REPLY нисходящую скорость 1 000 000 000 бит/с. Интерфейс показывает «доступно 1 Гбит/с», автоматизация сообщает об успешной настройке шейпера. Но при большой передаче задержка интерактивного трафика всё равно резко растёт.

Противоречия может не быть. Число может обозначать тарифный профиль, а не замер пути. Оно может считать кадры уровня 2, тогда как тест показывает полезную нагрузку уровня 3. Очередь могла оказаться на неактивном логическом интерфейсе. BNG мог установить меньший policer. Наконец, реальное узкое место может находиться за пределами контроля CPE.

Это аналитический сценарий, а не зафиксированная авария. Он показывает границу рабочей версии 00: протокол переносит намерение, но не удостоверяет его исполнение и эффект.

Три реестра для одного слова «скорость»

В доступе легко смешать три величины: продуктовую скорость, эффективную настройку shaper/policer/AQM и наблюдаемый результат конкретного потока.

Реестр Что следует хранить Что остаётся недоказанным
Сигнал исходная опция, направление, Rate Type, сообщение, транзакция, lease, сервер/ретранслятор применило ли значение какое-либо устройство
Эффективный контроль устройство, интерфейс, очередь, алгоритм, модель накладных расходов, запись и чтение после неё находится ли здесь узкое место и улучшился ли сервис
Результат ECN, drops, время в очереди, потери, задержка и доставка при определённой нагрузке кто утвердил продуктовую политику

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

Уровень подсчёта входит в смысл значения

Оба направления кодируются 64-битным беззнаковым числом в бит/с. Rate Type определяет, какие байты считаются.

Тип 2 означает уровень 2: заголовок Ethernet и нагрузка, без FCS и межкадрового интервала согласно рекомендуемому расчёту. Тип 3 — IP-заголовок и нагрузка, независимо от количества VLAN-тегов и туннелей. Если Rate Type отсутствует, получатель обязан принять уровень 2. Тип 0 — только информация; его нельзя применять к физическому интерфейсу, шейперу, policer или AQM.

Поэтому 1 Гбит/с L2 и 1 Гбит/с L3 не оставляют приложению одинаковую полезную полосу. Результат speed test может быть ниже L2-сигнала и не опровергать его. Панель, скрывающая тип, превращает ограниченное техническое утверждение в расплывчатое обещание.

Зарезервированный или неизвестный Rate Type отменяет всю OPTION_RATE. Неизвестный код подопции, напротив, пропускается, а обработка продолжается. При повторе одного кода берётся последний экземпляр. Аудит должен сохранять ветвь разбора, а не только нормализованное число.

У нуля две роли. Нулевая скорость направления снимает прежнее ограничение и возвращает стандарт устройства; это не измерение нулевой ёмкости. Нулевой Rate Type значит «только для отображения». Смешение оставит старое ограничение либо превратит сведения в команду.

Авторитет сервера ограничен протокольным актом

Клиент DHCPv4 может запросить опцию в PRL и предложить максимум или уровень в DHCPREQUEST. Это лишь подсказка. Сервер решает, а применимый ответ приходит в DHCPACK. Значение DHCPOFFER можно учитывать при выборе сервера, но нельзя применять к интерфейсу.

В DHCPv6 разделение аналогично: ORO просит опцию, Request может предложить, REPLY даёт применимый ответ. ADVERTISE не должен менять настройку. RECONFIGURE позволяет серверу вызвать Renew или Information-request до T1.

Сервер может получить значение из локального профиля, RADIUS/AAA или внешней политики. Ретранслятор DHCPv4, включая BNG, вправе добавить, изменить или убрать OPTION_RATE. Ответ может быть авторитетным для поведения клиента по тексту draft и при этом не быть физической истиной: профиль устарел, relay переписал данные или плоскость пересылки не соответствует им.

RFC 2131 и RFC 8415 задают состояния DHCP. RFC 3046 даёт контекст relay-информации, RFC 2865 — RADIUS. Ни один из них не читает очередь после настройки и не оценивает абонентский результат.

В одном обмене DHCPv6 может быть несколько локальных команд

Вложенные заголовки relay позволяют серверу поместить одно значение в клиентский REPLY и другие — на уровни конкретных ретрансляторов. Draft приводит пример, где восходящий policer relay немного выше шейпера CPE. Каждый relay должен потреблять адресованную ему копию, а не пассивно извлекать внутреннюю клиентскую.

Значит, единственной «скорости DHCP» может не существовать. Ключ записи включает направление, уровень инкапсуляции, адресата, источник политики, уровень подсчёта, lease и интервал действия. RFC 6221 описывает Lightweight DHCPv6 Relay Agent, но не подтверждает, что конкретное устройство поняло новую опцию или запрограммировало аппаратную очередь.

Dual stack превращает число в историю

DHCPv4 и v6 способны прислать конфликтующие скорости. Draft рекомендует предпочесть v6 и требует хранить исходный протокол вместе с применённым значением. Если lease v6 истёк, но v4 ещё действителен, сохранённая скорость далее считается полученной из v4. Если v4 отсутствует, устройство возвращается к умолчанию.

Безвременное поле «текущая скорость» не воспроизведёт это решение. Нужны идентификаторы lease, получение, срок, ветвь приоритета, замена и причина сброса.

PPPoE добавляет ещё одну границу. DHCP OPTION_RATE имеет приоритет над скоростью в ответе аутентификации PPP, однако сама PPP-сессия остаётся логическим основанием. Валидный ноль снимает настройку, а завершение сессии неявно отзывает её. RFC 2516 задаёт этот контекст. Сохранившийся после сессии лимит — уже не приоритет, а осиротевший приказ.

Физический предел — ограждение, а не карта

Если сервер сообщил 2 Гбит/с CPE с WAN-портом 1 Гбит/с, draft рекомендует ограничить эффективный shaping, policing или AQM физической ёмкостью. Управление должно показать исходное и ограниченное значения и записать расхождение.

Это доказывает только локальную верхнюю границу. Оно не доказывает доступность 1 Гбит/с и не находит узкое место. PON, агрегация, BNG, транзит или удалённый сервер могут быть медленнее. Корректное имя — «эффективная локальная скорость», а не «доступная ёмкость».

AQM нужна настоящая очередь

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

RFC 7567 даёт рекомендации AQM. RFC 9330, RFC 9331 и RFC 9332 описывают архитектуру L4S, протокол ECN и Coupled DualQ AQM. Для эффекта всё ещё нужны правильное размещение очереди, классификация, ECN-семантика, алгоритм и реагирующий контроль перегрузки.

Draft справедливо называет сигнал средством и оставляет детальную конструкцию AQM за рамками. Полученное число не выбирает qdisc, не привязывает его к активному egress и не показывает, снизилась ли задержка без потери использования.

Аутентификация останавливается на авторстве

Draft отмечает, что DHCP обычно передаётся открыто и без аутентификации. Ложный сервер или посредник может внедрить низкую скорость и локально задушить соединение. Порог минимальных значений и физический cap ограничивают крайности, но не устанавливают происхождение.

Даже подпись прежде всего докажет, кто сказал. Она не докажет свежесть профиля, неизменность relay, исполнение получателем и результат для пользователя. Идентичность, полномочие, исполнение и исход — четыре разных квитанции.

Running-Code Primacy ставит реально выполняемое поведение выше ярлыка. Minimum Initial Specification предлагает стандартизировать узкое совместимое ядро и оставить дальнейшие решения локальными и заменяемыми. Reality Layers разделяет символ, конфигурацию, физический механизм и наблюдаемый эффект.

Публикация draft не равна внедрению

Datatracker показывает версию 00 как активный Internet-Draft рабочей группы Internet Area с предполагаемым статусом Informational, опубликованный 27 августа 2026 года и истекающий 28 февраля 2027 года. История фиксирует замену индивидуальной версии. XML рабочей группы, карточка предшественника и индивидуальная версия 01 позволяют проверить линию.

Это ещё не RFC, коды опций остаются TBD. Источники не подтверждают поддержку продуктами, полевое развёртывание, совместимость, измеренное улучшение или реальный инцидент.

Источники