Кратко

  • RFC 5308 задаёт TLV 236 для достижимости IPv6, TLV 232 для IPv6-адресов интерфейсов и NLPID 142 для заявления о поддержке протокола. Это три утверждения разного уровня, а не единая квитанция о пересылке.
  • В общей стандартной топологии корректный IPv6-путь SPF нужно сопоставить со способностью каждого транзитного узла, состояниями RIB и FIB и результатом прохождения пакета. RFC 5120 делает участие в топологии явным, но также не доказывает доставку.

Маршрут может быть корректным только внутри модели

Префикс присутствует в базе состояния каналов. Метрика допустима, SPF выбрал ожидаемого предшественника, следующий переход разрешился. Оба конца работают с IPv6. На экране это выглядит как законченная причинная цепочка, хотя в действительности описана лишь часть пути.

Между концами может оказаться маршрутизатор, который законно участвует в обычной топологии IS-IS, но не обладает действующей IPv6-пересылкой в нужном интерфейсе, контексте или поколении FIB. Первое же IPv6-сообщение упирается в границу, которой нет на графе SPF.

Это не реконструкция конкретной аварии. Такая возможность следует из совместного чтения RFC 5308 и RFC 5120. Первый документ добавляет IPv6 в существующий механизм LSP, где уже соседствуют IPv4 и OSI. Второй позволяет разделять топологии, когда членство должно быть явным. В топологии по умолчанию смежность свидетельствует о связности IS-IS, а не о равной готовности всех семейств адресов на каждом транзитном устройстве.

Три элемента описывают три разные реальности

TLV 236, IPv6 Reachability, содержит префикс, 32-битную метрику, биты U, X и S и при необходимости под-TLV. U показывает распространение вниз по иерархии, X отмечает внешний источник из другого протокола маршрутизации, S сообщает о блоке под-TLV. Ни один из них не является отметкой об успешной пересылке пакета.

TLV 232 переносит адреса IPv6 интерфейсов, и его значение зависит от PDU. В Hello допустимы только link-local адреса отправляющего интерфейса. В LSP допустимы только не-link-local адреса, принадлежащие объявляющей промежуточной системе. Если хранилище оставит адрес, но выбросит тип PDU, оно удалит область действия утверждения.

NLPID 142 — третий слой. Система, поддерживающая маршрутизацию IPv6 через IS-IS, обязана включить этот идентификатор в TLV Protocols Supported. Это наиболее прямое заявление о способности из трёх, однако его делает процесс маршрутизации. Оно не удостоверяет готовность конкретной платы, VRF, разрешения соседа или текущей программы FIB.

Наличие в LSP не даёт права участвовать в обычном SPF

TLV 236 может встретиться в LSP ноль, один или несколько раз. Через него запрещено объявлять link-local префиксы. Байты префикса упаковываются до минимального размера, заданного длиной, поэтому доказательная запись должна сохранять и длину, и значащие байты, а не только нормализованную строку.

Для метрики есть дополнительная граница. RFC 5308 использует MAX_V6_PATH_METRIC, равный 0xFE000000. Префикс с большей метрикой нельзя учитывать при обычном расчёте SPF. Само объявление при этом может оставаться в базе для другой цели. Таким образом, стандарт прямо различает присутствие, синтаксическое принятие и право на обычный выбор маршрута.

Телеметрия не должна сводить это к одному состоянию «маршрут изучен». Полезная последовательность выглядит иначе: замечен в LSP, разобран, допущен к обычному SPF, выиграл сравнение предпочтений и метрик, получил следующий переход, установлен в RIB, запрограммирован в FIB, подтверждён доставкой. У каждого перехода свой владелец и свой отказ.

Подлинность сообщения не устраняет разрыв способности

Аутентифицированный LSP может совершенно честно сообщать о соседе и IPv6-префиксе. Это защищает происхождение и целостность данных, но не превращает процесс маршрутизации в свидетеля всей плоскости пересылки. У выбранного транзитного узла может отсутствовать пригодная запись IPv6 в FIB.

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

Поэтому общей топологии нужна внешняя инварианта: любой узел, который SPF может выбрать транзитным для IPv6, обязан иметь применимую способность в управляющей плоскости и в плоскости данных. Глобальная отметка инвентаря «IPv6 включён» слабее квитанции, связанной с конкретным предшественником, интерфейсом, контекстом, поколением RIB/FIB и наблюдением пакета.

RFC 5120 вводит явное членство в графе

RFC 5120 сообщает об участии в топологиях через IIH. На соединении точка-точка, если удалённая сторона не объявляет идентификатор топологии, локальный маршрутизатор не должен включать этого соседа в LSP соответствующей топологии. Если общей топологии нет вовсе, смежность формировать не следует. MT ID 2 зарезервирован для IPv6 routing, а TLV 237 ставит поле членства перед форматом IPv6-достижимости, унаследованным от TLV 236.

Правило для широковещательной LAN показывает, почему наличие смежности всё равно слишком грубо. На LAN смежность создаётся даже без общей мульти-топологии, чтобы участники выбрали одного DIS. Базовое соседство реально, но оно не разрешает использовать соседа в любой топологии. Для этого требуется фактически общее членство.

Раздельные графы IPv4 и IPv6 могут исключить несовместимый узел из IPv6-транзита. Вместе с этим появляются новые состояния: членство, отдельный overload, объявления TLV 237, результаты SPF и, возможно, разные RIB. Если несколько топологий одного семейства используют на интерфейсе перекрывающиеся адреса, RFC 5120 требует отдельный локальный механизм выбора RIB для входящего пакета. Протокол выразил различие, но не выполнил решение вместо оборудования.

RFC 7775 исправляет старый порядок предпочтений

Первоначально RFC 5308 располагал IPv6-маршруты в порядке Level 1 up, Level 2 up, Level 2 down, Level 1 down. Позднее RFC 7775 объяснил, что базовая двухуровневая модель не содержит типа Level 2 inter-area, который позволял бы определить такой класс «Level 2 down». Описание было заменено правилами, соответствующими реальным типам маршрутов TLV 236 и TLV 237.

Современная проверка реализации должна учитывать RFC 7775, а не считать перечень 2008 года окончательным. В журнале стоит сохранять TLV, топологию, уровень, биты U и X, исходный протокол, метрику, класс предпочтения и поколение SPF. Тогда после исправления стандарта решение можно пересчитать по исходным входам, не переписывая принятые байты LSP.

Квитанция должна пройти тот же путь, что и семейство адресов

Не раскрывающая секретов квитанция может связать идентичность узла, смежность и тип PDU; идентификатор топологии; Protocols Supported и IPv6 NLPID; адрес TLV 232 и контекст Hello либо LSP; префикс TLV 236 или 237, биты, метрику и под-TLV; поколение SPF; предшественника и следующий переход; всех членов ECMP; способность IPv6 каждого транзитного узла; выбор RIB; поколение и результат программирования FIB; link-local разрешение соседа; путь пробы; результат доставки и решение об откате.

Это не просто расширенный журнал. Такая цепочка сохраняет границу полномочий между процессом, который вправе описывать достижимость, и системой, обязанной переместить пакет. Граф может быть правильным как граф, а утверждение «IPv6 прошёл по этому пути» всё равно останется недоказанным.

Sources