Кратко

  • RFC 9673 обновляет RFC 8200 и задаёт выборочную, настраиваемую обработку IPv6 Hop-by-Hop Options в границах совокупной производительности пересылки.
  • Пакет может пройти через узел, который не распознал, не включил или намеренно пропустил опцию; доставка не является квитанцией исполнения на каждом hop.
  • Надёжная цепочка связывает платформу и build, таблицу типов, порядок и длину опций, маршрут и время, наблюдение по узлам, влияние на forwarding и результат приложения.

Вчера тест с опцией прошёл, и команда сохранила зелёный результат как свойство сервиса. Ночью IGP пересчитал маршрут, ECMP выбрал другую ветвь, а утром пакет встретил иной набор устройств. Старый тест не стал ложным. Он просто продолжал говорить правду о субъектах, которых на новом пути уже не было.

RFC 9673 обновляет RFC 8200, чтобы Hop-by-Hop Options можно было внедрять в современных маршрутизаторах и хостах. Он не возвращает обещание одинаковой работы каждого узла. Он позволяет локально выбирать опции и требует не жертвовать ради них совокупной пропускной способностью.

Общий минимум допускает разную работу

Ранние версии IPv6 требовали проверять Hop-by-Hop на всех узлах. На высокой скорости специальная обработка может уйти с fast path, конкурировать с control plane или стать поверхностью DoS. RFC 7045 описал практику extension headers. RFC 7872 зафиксировал значительные потери в исторических измерениях; RFC 9098 и RFC 9288 разбирают эксплуатационные последствия и фильтрацию. Эти данные объясняют риск, но не измеряют нынешний безымянный путь.

RFC 9673 требует, чтобы маршрутизатор, не обрабатывающий заголовок, обычно продолжал пересылку по последующим заголовкам и не отбрасывал пакет лишь из-за наличия Hop-by-Hop. Настроенное исключение возможно для защиты downstream-устройств, не способных безопасно следовать процедуре.

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

Бюджет нельзя выписать из RFC одной цифрой

Full Forwarding Rate означает работу без неблагоприятного влияния на совокупную скорость. RFC 9673 намеренно не задаёт универсальное число опций или байтов. Стоимость зависит от parser, pipeline, hardware revision, software, смысла и позиции опции, packet rate и нагрузки.

Не следует включать обработку первой опции, если она ухудшает совокупный forwarding. Дополнительные опции должны удовлетворять тому же условию. Один возможный механизм — настраиваемая lookup table типов, которые устройство способно обработать на полной скорости.

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

Операционное слово «бюджет» полезно, пока видны его измерения. Если превратить его в бейдж, поставщик получает монополию на перевод зелёного статуса в реальные ограничения — форму lock-in, скрытую за открытым стандартом.

Порядок распределяет дефицитную работу

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

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

RFC 9673 также делает конфигурационно зависимыми некоторые действия discard и ICMP, когда router не обрабатывает опцию. Семантика action bits неизвестного типа — отдельная тема. Здесь важнее право локального узла отказаться от работы, не прекращая пересылку.

Отсутствие ICMP не подтверждает поддержку

RFC 4443 задаёт ICMPv6. Полученный Parameter Problem показывает, что как минимум один узел не распознал опцию. Отсутствующий message не показывает обратного: его могли не создать, ограничить, отфильтровать или потерять; пакет могли передать без обработки.

Router Alert демонстрирует цену control-plane work. RFC 6398 описывает угрозу slow path. RFC 9673 оставляет исключение только с защитой — ACL, trust boundary, rate limiting или аналогичным механизмом. Запрос в пакете не даёт права на неограниченный процессор.

Более сильная квитанция привязана к узлу: счётчик или trace конкретного type, interface, build, policy generation и timestamp. После неё ещё требуется доказать эффект. Разбор, действие и польза сервису — разные переходы.

Path racing нужно повторять

RFC 9673 предлагает тестировать traffic с опцией и без неё, ждать acknowledgement и использовать fallback. В limited domain по RFC 8799 оператор может согласовать узлы. В открытом Интернете маршрут меняет участников.

Сохранять нужно exact bytes, type, порядок, total length, flow identity, доступное route evidence, время, критерий подтверждения, ICMP, per-hop telemetry и aggregate forwarding. У результата должна быть политика обновления после route churn, maintenance и software change.

RFC 9673 ценен не тем, что обещает универсальную поддержку. Новая опция должна быть простой, короткой, пригодной для full-rate, допускающей skip и полезной при частичном внедрении. Стандарт делает отказ безопасным; эксплуатация должна сделать его видимым и не выдавать вчерашний путь за сегодняшний.

Такой подход сохраняет свободу замены оборудования: сравниваются наблюдаемые границы, а не закрытые обещания одного поставщика.

Источники