Кратко

  • RFC 3359 собрал в общем списке используемые и предлагаемые номера TLV для IS-IS, чтобы уменьшить риск конфликтов, но прямо отказался от роли стандарта или органа распределения.
  • RFC 3563 превратил этот список в исходное состояние временного реестра IANA с проверкой назначенным экспертом. Запись номера не доказывает ни реализацию, ни применение в сети.

Конфликт может возникнуть ещё до появления ошибочного пакета. Две команды способны выбрать одно и то же восьмибитное значение для разных расширений, каждая внимательно проверив собственные документы. В сетевом пакете останется лишь номер; получатель не узнает, какая частная таблица должна иметь приоритет. Его программное обеспечение определит значение байта. Так два решения, разумные внутри своих групп, станут несовместимыми при встрече.

Опубликованный в августе 2002 года в категории Informational RFC 3359 предложил общее представление о TLV в IS-IS. Документ T. Przygiendy перечислил уже используемые или планируемые значения верхнего уровня и указал, в каких PDU — IIH, LSP или SNP — они применимы. Это не было полным описанием семантики каждого расширения. Задача была скромнее: дать следующим разработчикам увидеть, что выбранное ими число может быть занято или зарезервировано в чьей-то работе.

Таблица отражала неоднородную институциональную историю протокола. В ней соседствовали значения ISO 10589, IP-расширения из RFC 1195, проекты IETF, пункт DECnet с пометкой об устаревшем применении, а также проприетарные значения Lucent и Nortel. Совместное перечисление не приравнивало их нормативный статус. Оно показывало, что разные источники уже занимали одну и ту же числовую область на линии.

RFC 3359 точно обозначил пределы своей роли. Его цель — избежать возможных конфликтов в будущем, однако сам документ не является стандартом и не представляет органа, назначающего номера TLV. Распределение шло на общей информационной основе между группами ISO, SIF и IETF. ISO не предоставляла орган нумерации, а ответственность IANA в тот период описывалась как ограниченная кодовыми точками, связанными с IP. Поэтому авторы указали, что правдоподобного центрального органа тогда не существовало.

Список всё равно мог влиять на выбор. Если автор расширения видел, что значение занято или уже рассматривается, он мог взять другое. Здесь работала общая видимость и заинтересованность в совместимости, а не механизм наказания. Документ не измерял, сколько конкретных коллизий удалось предотвратить. Он описывал назначение списка, а не подтверждённый эксплуатационный результат.

Ограничения были явными. RFC 3359 не указывал для каждого числа отдельный документ, задающий его формат, и не решал вопрос с кодами sub-TLV. Он предполагал периодические обновления и допускал будущую замену официальным реестром. Строка таблицы предупреждала о повторном использовании, но не давала полной истории источников, правил совместимости или доказательств программной поддержки.

В том же 2002 году RFC 3232 зафиксировал переход от периодического переиздания общего перечня Assigned Numbers к онлайн-базе данных. Для изменяющегося пространства параметров постоянно поддерживаемый реестр практичнее очередного статического RFC. В случае IS-IS добавлялась граница между организациями: ISO отвечала за базовый протокол, IETF разрабатывала расширения для Интернета, а реализации из других источников уже использовали свои значения. Нужно было договориться не только о том, где смотреть номера, но и кто утверждает назначения, обновляет данные и сообщает об изменениях другим.

RFC 3563 в 2003 году опубликовал соглашение о сотрудничестве ISOC/IETF и ISO/IEC JTC1/SC6. Оно разделило области работы над базовым IS-IS и интернет-расширениями, а IANA поручалось временно вести реестр TLV до появления регистрационной службы JTC1. Слово «временно» имело практический смысл: после уведомления полномочия распределения могли перейти JTC1, тогда как IANA могла сохранить информационную копию и обновлять её по поступающим данным.

Хранение страницы, утверждение номера и сопровождение стандарта оказались разными задачами. Начальное состояние реестра следовало синхронизировать с RFC 3359. Старый перечень стал исходной точкой формальной процедуры, а не материалом, который нужно отбросить. Новые назначения требовали одобрения эксперта, назначенного IESG. IETF должна была информировать JTC1/SC6 о выданных номерах, а JTC1/SC6 — направлять запросы своих участников в процесс IANA. Взаимное уведомление стало частью процедуры, а не негласным ожиданием.

Менялась и структура записи. RFC 6233 добавил столбец Purge, показывающий, какие TLV разрешены в очищенном LSP. Контекст PDU влияет на допустимость значения, но столбец остаётся кратким ориентиром; полное правило содержится в спецификации, определяющей этот TLV.

В 2014 году RFC 7370 объединил связанные реестры sub-TLV и описал работу назначенных экспертов с запросами до публикации RFC. Обычно запрос должен опираться на документ, принятый рабочей группой; если такой группы нет, применим путь при поддержке директора области. Эксперт проверяет наличие консенсуса либо одобрения, оценивает техническую обоснованность, но не отменяет консенсус IETF. Если проект не проходит дальше, временное назначение может истечь и быть возвращено по правилам раннего распределения.

RFC 7120 задаёт общую дисциплину ранних назначений, а RFC 7370 объясняет её для реестров IS-IS с политикой Expert Review. RFC 8126 описывает названия и смысл политик регистрации, но не подтверждает наличие реализации. В 2024 году RFC 9650 изменил для одного реестра битов атрибутов связи политику с Standards Action на Expert Review: прежнее ограничение мешало экспериментам и повышало риск использования незарегистрированных значений. Слишком свободный доступ может вести к коллизиям; чрезмерная строгость вытесняет испытания из общего реестра.

Нынешняя страница IANA — это обновляемый результат такой эволюции. В ней есть верхнеуровневые и вложенные реестры, применимость к PDU, ссылки и политики, которых не было в таблице 2002 года. Здесь она рассматривается как датированный современный срез, а не как описание первоначального RFC 3359.

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

Источники