Кратко

  • RFC 9947 требует применять экспериментальный SRH TLV для Alternate Marking только в контролируемом SR-домене, но ожидает, что результаты добровольных опытов в работающих сетях будут переданы Independent Submissions Editor или рабочей группе IETF SPRING в виде Internet-Drafts. Удержание пакета и разрешение на публикацию данных — разные меры контроля.
  • Публичному результату нужна запись о выпуске доказательств: полномочие на раскрытие, версии текста и реализации, экспериментальный код, реализованные поля, сравнение с RFC 9343, группы оборудования, выборка, неопределённость, отрицательные итоги, правила агрегации, хэши и исправления — без сырых пакетов, идентичности клиентов и уязвимой топологии.

Закрытый опыт предназначен для открытого спора

RFC 9947 опубликован в марте 2026 года как Experimental RFC в Independent Stream. Расширение разработано вне IETF, не имеет консенсуса IETF и не претендует на какой-либо уровень Internet Standard. Постоянного назначения IANA оно тоже не создаёт.

Документ предлагает помещать данные Alternate Marking для SRv6 в TLV заголовка Segment Routing. Стандартный RFC 9343 переносит их в IPv6 Hop-by-Hop или Destination Options. Эти способы могут сосуществовать; новый не отменяет старый.

Эксперимент должен выяснить, лучше или хуже SRH TLV сохраняется на пути, ускоряет или замедляет обработку по сравнению с Destination Option, одинаково ли реагируют разные архитектуры устройств, не нарушаются ли обычное программирование SRv6 и управление функциями SID, а также насколько полезны расширенные поля по сравнению с другой телеметрией на пути.

Ответы предполагается собрать после публикации RFC и направить Independent Submissions Editor или SPRING в виде Internet-Drafts. Начальные результаты ожидаются в течение двух лет. Этот срок ещё не прошёл, а сама формулировка является ожиданием, не основанием утверждать чью-либо просрочку.

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

Контролируемый домен решает задачу плоскости данных

Эксперимент обязан оставаться в контролируемом домене. Один оператор решает, применять ли Alternate Marking и как его настроить. Узлы администрируются локально, а пакеты с AltMark TLV не должны входить в домен или покидать его.

Тип TLV выбирается из экспериментального диапазона 124–126. Участники согласуют значение, а оператору желательно иметь возможность менять его, чтобы несколько опытов не конфликтовали. Это локальная договорённость, не регистрация и не разрешение на широкое внедрение.

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

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

Реализованный набор полей — часть результата

Базовый TLV несёт 20-битный FlowMonID, флаги потери и задержки. Расширенный вариант может включать дополнительный FlowMonID, режим по сегментам или из конца в конец, признак фрагментации, направление, отметку времени, управление наблюдением обратного потока и номер последовательности. Для обратного направления учитываются маски префиксов, протокол, порты, DSCP, область туннеля и период.

Поэтому фраза «поддерживает RFC 9947» не задаёт единого опыта. Объём работы зависит от включённых полей, поведения SID и числа конечных точек, способных обрабатывать TLV. Узел, который не поддерживает функцию, вправе игнорировать TLV по правилам SRH; это не обязательно дефект.

Ветка RFC 9343 тоже требует симметричного описания. Если у неё иной набор полей, длина пакетов, нагрузка, маршрут или оборудование, точная цифра сравнивает сразу несколько изменений. Без этой информации преимущество нельзя приписать размещению данных в SRH.

Экспериментальное значение — ещё один ключ происхождения. Передатчик с 124 и приёмник, ожидающий 126, создадут картину несовместимости из-за настройки. Совпадение с другим опытом может смешать наблюдения. Указание кода не повышает статус решения, а позволяет связать измерение с правильной конфигурацией.

У метаданных остаётся контекст

RFC 9343 отмечает, что Alternate Marking не публикует пользовательские данные, однако его метаданные могут помочь разведке сети. FlowMonID может способствовать отслеживанию потока, а несколько синхронных точек наблюдения — раскрыть маршрут и производительность. Каналы передачи статистики в систему управления должны быть защищены.

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

RFC 8799 различает конфиденциальность эксплуатационных параметров limited domain и приватность отдельных пользователей. При публикации затрагиваются обе. Удаление названий не помогает, если точное время, редкий класс трафика, форма маршрута и малая выборка снова указывают на конкретную активность.

Но конфиденциальность не должна оставлять одну благоприятную фразу. Если исчезли знаменатели, исключения, остановленные прогоны и группы устройств, читатель не может проверить альтернативные объяснения. Безопасный выпуск должен сохранять структуру сравнения, а не отдельные сырые строки.

Четыре части записи о выпуске

Первая — полномочие. Следует назвать оператора или спонсора, роль, одобрившую раскрытие, место и время подачи, а также существенные отношения финансирования или поставки оборудования. Получение текста ISE или его обсуждение SPRING не означает одобрения либо консенсуса IETF.

Вторая — техническая идентичность: редакция RFC или Internet-Draft, сборка реализации, значение TLV, базовые и расширенные поля, поведение SID и конфигурация сравнения по RFC 9343. Хэши позволяют зафиксировать защищённые артефакты, не публикуя их.

Третья — популяция. Архитектуры, версии ПО и прошивок можно сгруппировать достаточно подробно для объяснения различий, но без создания опасной инвентарной ведомости. Нужны абстрактная форма пути, интервал наблюдения, допустимый и исключённый трафик, обработка выборки, предпосылки часов и счётчиков, определения потери, задержки, вариации, сохранности и стоимости обработки.

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

Это редакционное предложение Daniel Kade, а не обязательное поле RFC 9947. Оно не требует полного набора данных. Его назначение — показать, каким образом защищённое наблюдение стало ограниченным публичным выводом.

Работающий код не становится голосом IETF

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

Однако Independent Stream прямо исключён из области RFC 7942. Нельзя превращать этот BCP в обязательный контракт для RFC 9947. Полезен лишь принцип: свидетельство реализации должно иметь владельца, охват и дату.

RFC 7841 сохраняет другую границу. Сильный результат не превращает Independent Stream RFC задним числом в консенсус IETF. Он может побудить новое обсуждение или повлиять на будущий выбор. Качество доказательства и институциональное происхождение документа остаются разными характеристиками.

Граница выводов

Источники подтверждают статус RFC 9947, формат полей, требование контролируемого домена, вопросы сравнения и ожидание передачи результатов. Они подтверждают связанный контекст приватности, целостности и SRv6. В них нет результатов конкретного оператора, списка внедрений или открытого набора данных.

Эта статья не выбирает победителя между SRH TLV и RFC 9343. Она не утверждает, что результаты отсутствуют или задерживаются. Она не требует сырых пакетов, клиентов, точной топологии или секретов поставщика.

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

Источники

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. Карточка RFC 9947 в RFC Editor
  5. RFC 9947 — Alternate-Marking Method в Segment Routing Header
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — применение Alternate-Marking Method в IPv6
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — SRv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code