Кратко

  • ipv6ExtensionHeadersLimit=false означает ограниченное описание из-за предела проверки; true — соответствие полному набору содержащихся заголовков расширения. Название поля не должно переворачивать эту семантику.
  • RFC 9740 отдельно описывает тип, последовательные повторы, порядок и длину цепочки. Возможность представить наблюдаемую опцию не доказывает ни её успешную обработку получателем, ни поддержку формата всеми устройствами.
  • Пропуски и ограниченные наблюдения следует отделять от обоснованных нулей. Рост числа обнаруженных типов после обновления может отражать расширение видимости, а не рост использования.

Три инструмента и один неверный вывод

Представим HIP в дальней части цепочки IPv6. Один экспортёр проходит всю цепочку. Другой достигает предела проверки раньше. Третий использует старое поле, в котором HIP не представим. Если последние два результата получают подпись «HIP отсутствует», неизвестность стала отсутствием, которого никто не установил. Это условный пример, а не результат испытания определённого продукта или сети.

RFC 9740, опубликованный в марте 2025 года в категории Standards Track IETF, добавляет двенадцать информационных элементов IPFIX и тип unsigned256. Старый ipv6ExtensionHeaders (64) имел фиксированное множество представимых типов, не охватывавшее, в частности, HIP с номером протокола 139, Shim6 с номером 140 и экспериментальные расширения. Он явно не описывал порядок, повторения, длину цепочки и полноту против ограниченности отчёта. tcpOptions (209) представлял только Kinds до 63 и не различал эксперименты, совместно использующие 253 и 254. Оба элемента признаны устаревшими. Переименование исторического столбца не расширяет задним числом полученное наблюдение.

Полнота — тоже локальное утверждение

Ключевое правило содержится в §3.5. Элемент 517 имеет значение false, если экспортируемые сведения охватывают лишь доступную до предела часть, обычно из-за аппаратных или программных ограничений. True означает соответствие полным содержащимся заголовкам расширения. Отсутствие 517 не является положительным заявлением о полноте.

И кодирование здесь не совпадает с привычным программным флагом. RFC 7011 §6.1.5 кодирует boolean true числом 1, false числом 2; остальные значения не определены. Поэтому сырой ноль нельзя считать стандартным false. Это отдельный вопрос от корректного нулевого значения битовой карты.

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

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

Что именно сохраняет описание цепочки

RFC 8200 описывает последовательность расширений IPv6, связанных значениями Next Header до верхнего уровня. ipv6ExtensionHeaderType (513) сообщает наблюдаемый код типа. ipv6ExtensionHeaderCount (514) считает последовательные появления одного типа: это не число пакетов, пользователей или внедрений.

ipv6ExtensionHeaderTypeCountList (516) сохраняет порядок пар «тип — количество». В последовательности Hop-by-Hop, Destination Options, Fragment, Destination Options две позиции Destination Options остаются отдельными. Разные цепочки внутри Flow необходимо описывать раздельно. Если реализация определила наблюдаемый код как заголовок расширения, она обязана сообщить точный код, даже не поддерживая его функцию. Определить, означает ли неизвестный Next Header расширение или протокол верхнего уровня, — самостоятельная задача классификации.

Битовая карта ipv6ExtensionHeadersFull (515) сообщает присутствие типа хотя бы в одном наблюдаемом пакете Flow, но не восстанавливает порядок. Позиции задаёт реестр IANA IPFIX, а не напрямую номер протокола: Destination Options, 60, соответствует биту 0; Hop-by-Hop, 0, биту 1; HIP, 139, биту 10. No Next Header включён как особый случай, хотя это не заголовок расширения. RFC запрещает совместный экспорт 515 и516. Набор флагов не превращается в упорядоченную цепочку.

ipv6ExtensionHeadersChainLength (518) суммирует длину расширений в октетах, исключая основной заголовок IPv6 и заголовок верхнего уровня. Это не количество заголовков. ipv6ExtensionHeaderChainLengthList (519) соединяет 515 и518 и разделяет разные цепочки. При использовании 519 их карты нельзя объединять; без списка RFC допускает определённые совмещённые или отдельные описания. Присутствие плюс длина не возвращают порядок и не дают знания о непроверенном остатке частичного отчёта.

Обновление может изменить статистику раньше трафика

Для TCP tcpOptionsFull (520) напрямую сопоставляет Kind от 0 до255 его битовой позиции. Так можно представить наблюдаемую опцию, не поддерживая её функцию. Для IPv6 новые назначения расширений отражаются в следующем свободном бите реестра IPFIX; исключения с отдельными поведенческими битами проходят Expert Review. Изменение реестра не обновляет автоматически все установленные программы.

Логические 256 бит не всегда требуют передачи 32 октетов. Сокращённое кодирование позволяет опустить допустимые ведущие нули; Template указывает фактическую длину поля. Присутствующее корректно сокращённое значение не является пропуском. Широкий целочисленный тип в хранилище тоже не доказывает глубину проверки экспортёром.

RFC 6994 различает эксперименты, разделяющие Kinds 253 и254, по16- или32-битным ExID. Списки ExID в RFC 9740 имеют приоритет: если они присутствуют для Flow, общие биты соответствующих Kinds должны оставаться нулевыми. Аналитика только по карте может пропустить положительное свидетельство. Автономное распознавание и определение ширины предполагают действительный список ExID, поддерживаемый реализацией; формат сам по себе его не обеспечивает.

Переход от64 или209, более глубокий анализатор или новая таблица могут показать больше типов в неизменившемся трафике. Стабильная серия, напротив, может скрывать рост слепой зоны при усложнении цепочек. Перекрывающиеся измерения сравнимой совокупности помогают отделить изменение видимости от изменения использования. Без перекрытия нужны объявленный разрыв серии и оставшаяся неопределённость. Заполнение прежнего непредставимого или непроверенного участка нулями сглаживает линию ценой выдуманного свидетельства. Источники подтверждают семантику стандарта, а не текущую мировую распространённость или успешность конечной обработки.

Источники