Кратко

  • Расширение RFC 4950 добавляет к некоторым ошибкам ICMP стек MPLS в том виде, в каком он поступил на сообщающий маршрутизатор.
  • Этот снимок дополняет цитату IP-пакета, но не показывает автоматически выходное состояние, обратный путь ошибки или глобальную идентичность меток.
  • Пример вывода в RFC не является измерением сегодняшней сети. Видимость зависит от формирования ответа, его доставки, политики оператора и способа разбора.

Как пример превращается в лишний вывод

В RFC 4950, опубликованном в августе 2007 года, есть пример вывода расширенного traceroute. Помимо адресов и времени ответа он показывает данные MPLS: метку, поле EXP, TTL и признак дна стека.

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

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

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

Чего не было в обычной цитате

Причина появления расширения находится не на экране, а в обработке пакета.

Маршрутизатор коммутации по меткам получает MPLS-дейтаграмму, которую не может доставить. Он снимает весь стек, открывает вложенную IP-дейтаграмму и передаёт её обработчику ошибок. Возникшее сообщение ICMP может объяснить причину отказа, процитировать IP-заголовок и начало исходной полезной нагрузки.

При этом в нём не остаётся стека, с которым пакет пришёл. Именно этот стек служил бы основой решения о дальнейшей пересылке. Цитата может точно воспроизводить IP-данные и всё же не сохранять важный контекст их обработки.

Расширение предлагает прикладывать входящий стек к выбранным сообщениям. Исходный IP-заголовок и начало нагрузки при этом должны оставаться. Новая часть не заменяет прежнюю: они отвечают на разные вопросы.

Одна связывает ошибку с исходным обменом. Другая показывает часть состояния пересылки на входе в конкретный узел.

Восемь байтов были нужны для сопоставления

В сентябрьском RFC 792 1981 года формат Time Exceeded включал IP-заголовок и первые 64 бита данных исходной дейтаграммы. Эти восемь байтов помогали получателю сопоставить сообщение с нужным процессом. Если протокол более высокого уровня использовал номера портов, предполагалось, что они находятся в начале данных.

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

Для MPLS простое удлинение IP-цитаты всё равно не гарантировало восстановления пропавшего контекста. Стек стоял перед IP-заголовком, а не после процитированных данных.

Январский RFC 3032 2001 года помещает стек между заголовками канального и сетевого уровней. Каждая запись занимает четыре октета. Верхняя идёт первой, последняя обозначается битом S.

Поиск по верхней метке определяет следующий узел и действие над стеком: замену, удаление записи либо замену с добавлением новых. Поэтому отсутствие стека — не просто потеря удобной подписи. Из отчёта исчезает часть состояния, участвующего в выборе пересылки.

У снимка есть точка во времени

RFC 4950 определяет один объект для всего стека, сохраняя порядок и формат на момент поступления пакета в маршрутизатор, который отправляет ошибку. Объект можно добавлять к Time Exceeded и Destination Unreachable для ICMPv4 и ICMPv6. Это не разрешение использовать его во всех типах ICMP.

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

В заголовке объекта используются Class-Num 1 и C-Type 1. Длина равна четырём октетам заголовка плюс четырём на каждую запись. Для трёх записей получится шестнадцать октетов. Это расчётный пример формата, а не захват трафика. Общий заголовок расширения, расположенный перед объектом, в эту длину не входит.

Запись содержит двадцать бит метки, три бита с тогдашним названием EXP, один бит S и восемь бит TTL. В феврале 2009 года RFC 5462 переименовал EXP в Traffic Class, или TC, уточнив назначение поля. Размер записи от этого не изменился.

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

Совпадение чисел ещё не связывает узлы

RFC 3031 определяет метку MPLS как локально значимый идентификатор класса эквивалентности пересылки. Она не является кодировкой IP-адреса назначения.

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

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

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

Если сохранить в архиве только число, а контекст отбросить, позже появляется соблазн соединить одинаковые значения в карту. Красивое соответствие в таблице не заменяет знания о том, где и когда эти значения действовали.

Дополнение пришлось отделить от оригинала

Для передачи объекта потребовалась структура из RFC 4884, вышедшего в апреле 2007 года. В некоторых сообщениях ICMP после области исходной цитаты располагаются один заголовок расширения и один или несколько объектов.

Граница должна быть явной. Документ вводит восьмибитный атрибут длины на месте ранее зарезервированных октетов. В ICMPv4 длина области цитирования выражается в 32-битных словах, в ICMPv6 — в 64-битных.

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

Но у уже существовавших программ оно имело другое значение. RFC 4884 описывает реализации, выпускавшиеся с 1999 года до публикации документа: они добавляли расширение после ровно 128 октетов цитаты, не указывая новый атрибут длины.

Некоторые читатели искали расширение только в фиксированной позиции. Отправитель мог перейти к более длинной цитате, а новый читатель — следовать объявленной длине. Старый продолжал бы смотреть в прежнее место.

Чтобы сохранить совместимость с такими программами, отправителю следовало оставить ровно 128 октетов. Если эта совместимость не требовалась, он мог передавать больше в пределах ограничений размера сообщения. Формат описывал выбор, но не обновлял установленное программное обеспечение.

Нулевая длина и отдельный режим

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

Поэтому документ требует от соответствующего traceroute отдельного, не используемого по умолчанию режима совместимости. В достаточно длинном ответе без длины такой режим ищет заголовок на старой фиксированной позиции и проверяет версию и контрольную сумму.

Это не одно и то же, что обычное следование явной границе. Зная режим, можно объяснить, почему две программы по-разному показывают одни байты. Без этого различие легко принять за изменение сети.

Классические приложения, вовсе не понимающие расширений, могут считать добавленные данные продолжением цитаты оригинала. RFC рассматривает известные последствия, а не гарантирует безвредность для любой старой программы.

Заголовок расширения использует версию 2. Неизвестный объект сам по себе не делает всю ICMP-структуру неправильной, но длины и синтаксис необходимо проверять. Контрольная сумма не служит криптографическим удостоверением источника. Правильно разобранная запись остаётся сообщением, происхождение которого может требовать отдельной проверки.

Не путать свидетельство с транспортом

Другой сюжет, изложенный ещё в RFC 3032, касается доставки самой ошибки. Внутренний маршрутизатор MPLS-домена может не знать прямого маршрута к исходному IP-отправителю.

Для определённых случаев описан способ сначала отправить созданное сообщение ICMP в сторону первоначального назначения, используя метки, пока оно не достигнет маршрутизатора, способного вернуть его источнику. Значения меток копируются, но TTL задаются для путешествия нового сообщения.

Эта внешняя инкапсуляция активно направляет отчёт. Объект RFC 4950 внутри отчёта, напротив, хранит состояние входа другого, не доставленного пакета.

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

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

Почему не каждый узел становится видимым

В RFC 3443, опубликованном в январе 2003 года, различаются модели обработки TTL. Uniform согласует внутренний и внешний TTL на входе и выходе туннеля. В моделях Pipe исходное внешнее значение может не зависеть от внутреннего.

Поэтому изменение TTL внутри IP-пакета не обязано вызывать ожидаемое истечение на каждом внутреннем переходе MPLS-пути. Это не означает бесконечный внешний TTL или запрет любого ICMP. Оно означает, что условия возникновения нужной ошибки остаются самостоятельной частью метода.

RFC 4950 прямо не берёт на себя изменение этих условий. Расширение дополняет уже полученные ошибки, а не создаёт все недостающие наблюдения.

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

Отсутствие строки MPLS поэтому допускает несколько объяснений: данные не созданы, не доставлены, не раскрыты или не распознаны. Оно не является достаточным доказательством отсутствия MPLS.

Сам RFC говорил в 2007 году, что механизм уже широко развёрнут. Это историческое утверждение документа, не статистика сегодняшнего использования и не дата одновременного включения во всех сетях.

Полезный итог скромнее готовой карты, но надёжнее её видимости: отчёт научился сохранять определённый входящий контекст, прежде легко терявшийся при подготовке IP-ошибки.