Кратко

  • Начиная с RFC 1883 два старших бита IPv6 TLV Option Type определяют действие узла, который не знает этот тип: пропустить опцию, отбросить пакет либо отбросить и вернуть ICMPv6 с указателем на неизвестный байт.
  • Третий бит сообщает, могут ли данные изменяться по дороге. Он ограничивает последствия незнания и область аутентификации, но не гарантирует обработку каждым маршрутизатором, пропуск каждым middlebox или достоверность содержимого.

Старой реализации было достаточно увидеть границу

Конечный узел распознаёт Destination Options и идёт по TLV. Очередного типа в его коде нет. Значение остаётся непрозрачным, но длина показывает, где оно кончается и начинается следующая опция.

RFC 1883, первая опубликованная спецификация IPv6 декабря 1995 года, поместила в тот же октет и резервное действие. Два старших бита описывали реакцию на незнакомый тип, следующий — изменчивость данных до конечного адресата. Остальные пять тоже участвовали в идентичности.

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

Два бита задавали четыре последствия

00 означает перейти через опцию по её длине и продолжить разбор заголовка. 01 — отбросить пакет. 10 — отбросить и отправить источнику ICMPv6 Parameter Problem, Code 2, поставив указатель на неизвестный Option Type. 11 делает то же, но не отправляет сообщение, если адрес назначения multicast.

Это не шкала опасности. Содержимое опции 00 может противоречить локальной политике. Опция 11 может быть законной, но требовать понимания для сохранения смысла. Кодируется цена незнания, а не намерение отправителя.

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

Для multicast граница отчёта была отдельной

Разница между 10 и 11 проявляется только при multicast-назначении. Первый требует отчёт и тогда, второй его подавляет. Значит, потенциальный обратный трафик ошибки виден в самом типе, а не выбирается каждой реализацией по догадке.

Оператор всё равно отвечает за rate limit и защиту ресурсов и сверяет правило с реально отправленными пакетами. Биты не объявляют multicast атакой и не обещают доставку ошибки.

Третий бит не позволял заверять изменяемую фикцию

Следующий бит отвечает на другой вопрос. Ноль сообщает, что Option Data не меняется по пути; единица — что может меняться. Если пакет содержит Authentication Header, изменяемые данные при вычислении и проверке значения аутентификации рассматриваются как нулевые октеты.

Поле, которое законно обновляется в пути, нельзя одновременно обещать неизменным. IPv6 исключил именно эту область. Но бит не раздаёт право записи: кто и как меняет поле, по-прежнему определяет спецификация конкретной опции.

Идентичностью были все восемь битов

RFC 2460 в 1998 году уточнил: три старших бита не являются отдельной политикой поверх пятибитного номера. Весь восьмибитный Option Type идентифицирует опцию. Совпадение нижних пяти при разном префиксе означает разные типы.

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

Порядок сохраняет причинность: раннее требование отбросить нельзя отменить задним числом знакомым полем в конце.

Неизвестная опция не была неизвестным Extension Header

Биты действия находятся внутри TLV в уже распознанном Hop-by-Hop Options или Destination Options. Неизвестное значение Next Header не получает от них автоматически ни длину, ни те же правила.

RFC 6564 поэтому предпочёл новую Destination Option, когда её достаточно, и потребовал обоснования для нового Extension Header. Будущим необходимым заголовкам дали общий формат с длиной, но прежние форматы не стали единообразными задним числом.

RFC 7045 разделил роли. Конечный хост отбрасывает пакет с неизвестным Extension Header. Транзитный узел обычно не должен отбрасывать лишь потому, что ещё не знает нового заголовка; если он инспектирует цепочку, ему следует поддерживать знание реестра. Это иной договор, чем чтение action bits неизвестного TLV в известном контейнере.

Middlebox показал предел самописания

Firewall, балансировщик и быстрый маршрутизатор нередко ищут транспортные порты. Длинная или новая цепочка может потребовать recirculation, вывести пакет из fast path либо не дать политике найти нужные поля.

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

Самоописание не создаёт аппаратной мощности. Оно лишь делает предсказуемым незнание процессора, который уже дошёл до TLV.

Чего биты никогда не разрешали

00 не означает безопасность и право прохода. 11 не доказывает враждебность. Бит изменчивости не разрешает произвольную запись. Регистрация не доказывает поддержку пути, а ICMP не удостоверяет личность или намерение.

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

Источники и границы доказательств

Семантика возникла в RFC 1883, уточнена в RFC 2460 и сохранена в RFC 8200. Границы форматов и транзита даны RFC 6564 и 7045, эксплуатационные ограничения — RFC 9098. Они не измеряют сегодняшнюю поддержку и потери во всех продуктах и сетях.