Кратко

  • RFC 2042 зарезервировал значение типа 255 для разработки новых атрибутов BGP. Для реального использования в Интернете атрибут следовало описать в RFC, получить уникальный type code от IANA, а затем обновить документацию и кодовую базу.
  • Документ прямо отверг деление пространства на public/private и Internet/OSI. Поэтому наличие 255 не доказывает частное расширение поставщика, совместимость реализаций, внедрение, принятие, безопасность, совместимость версий или разрешение на эксплуатацию.

Паспорт должен отличать один объект от другого. Значение 255 в RFC 2042 делало обратное: оно объединяло незавершённые разработки в одну временную категорию и намеренно не сообщало, какой именно эксперимент скрывается за байтами.

Документ вышел в январе 1997 года как Informational RFC. Сейчас RFC Editor относит его к Legacy stream, а IETF Datatracker указывает, что он не одобрен IETF и не имеет формального статуса в процессе стандартизации IETF. Это важное ограничение: перед нами историческая схема координации, а не универсальное современное разрешение.

Общий номер без общей семантики

RFC 1771 тогда описывал BGP-4 и известные атрибуты пути. RFC 2042 отвечал на более узкий вопрос: какой код использовать разработчику нового атрибута до появления публичного номера? Для этой стадии был оставлен однобайтовый 255.

Разные лаборатории могли поместить после 255 разные флаги, длины и форматы. В закрытом испытании смысл восстанавливался из предварительной договорённости, версии сборки и конфигурации соседей. В изолированной трассе число не отличало один формат от другого.

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

Неуникальность была полезна: краткоживущие прототипы не расходовали общий реестр. Но она же требовала удерживать эксперимент внутри границы, где контекст известен. За этой границей временную метку нужно было заменить.

Как появлялась публичная идентичность

Для фактического применения в Интернете RFC 2042 требовал документировать атрибут в RFC и получить уникальный type code у IANA. После присвоения документацию и кодовую базу следовало перевести на разрешённое значение.

Это три разных перехода. Спецификация делает смысл проверяемым. Реестр предотвращает конфликт публичных номеров. Изменение программы заставляет конкретную реализацию отправлять новый код. Завершение одного шага не подтверждает остальные и не доказывает успешный обмен.

Если документ уже содержит новый номер, а старая сборка продолжает отправлять 255, описанная и исполняемая реальность расходятся. Если отправитель обновился раньше получателя, законно присвоенный атрибут всё ещё может быть отвергнут. Если анализатор трафика сохранил старую таблицу, правильный пакет может выглядеть ошибкой. Надёжная история перехода связывает запись IANA, редакцию RFC, commit, тестовые векторы, сборку и наблюдение за развёрнутой версией.

Не частный диапазон

RFC 2042 отдельно говорит, что пространство кодов не предполагалось делить на публичные и частные части либо на части для Internet, OSI и иных применений. Следовательно, 255 не был кодом производителя или корпоративным карманом. Это одна общая временная метка разработки.

Нынешний реестр IANA BGP Path Attributes по-прежнему называет 255 «Reserved for development» и ссылается на RFC 2042. Диапазона Private Use в этой таблице нет. В других реестрах набора BGP Parameters встречаются vendor-specific или private-use правила, но политика относится к конкретной таблице. Её нельзя переносить на Path Attributes лишь из-за общего слова BGP.

Современная таблица Path Attributes также указывает процедуру Standards Action со ссылкой на RFC 4271 — более позднюю Standards Track спецификацию, сменившую RFC 1771. RFC 8126 определяет нынешнюю терминологию регистрационных политик. Это современный слой управления, а не формулировка, которую можно приписать RFC 2042 задним числом.

Уникальное присвоение подтверждает состояние реестра: за номером записано значение по установленной процедуре. Оно не подтверждает наличие кода, внедрение, распространённость, безопасность, совместимость или эксплуатационное разрешение.

Редакционная идея Heng Lu о первичности работающего кода помогает удержать границу, но не является требованием IETF. Публикация и регистрация относятся к институциональной реальности; сборка — к исполняемой; работа соседей и сети — к операционной. Между слоями нельзя переходить без нового наблюдения.

Исправлена ссылка, не правило

Официальная Errata ID 3681 исправляет ссылку на документ о BGP Route Reflection: правильный номер RFC 1966, а не RFC 1998. Исправление имеет тип Editorial и статус Held for Document Update. Оно не меняет назначение 255 и порядок регистрации.

Заметная опечатка в английском слове «documentation» не является предметом этой официальной errata. Такое различие важно: исследователь должен сообщать то, что подтвердил реестр исправлений, а не подменять это самой очевидной ошибкой на странице.

Слабая метка как полезный инструмент

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

Общий слой оставался минимальным: публичный атрибут получает документированный смысл и уникальную метку. Готовность программы, решение о внедрении и совместимость с соседями проверяются отдельно.

IANA может показать, какой номер публично обозначает какой атрибут. Реестр не показывает, работает ли он. А общий 255 сам по себе не показывал даже того, какой эксперимент обозначает.

Источники