Кратко

  • RFC 1326 соединил X-в-Y и Y-в-X возможной петлёй маршрутизации. Пакет получал очередную оболочку до того, как достигал выхода из предыдущего туннеля.
  • Если новый внешний заголовок не сохранял прежний счётчик переходов, активный срок жизни начинался заново. После достижения MTU фрагментация превращала рост одного пакета в рост их числа.
  • Перенос счётчика, просмотр внутренних заголовков и запрет отдельных вложений имели пределы. Составной путь требовал единого бюджета, который нельзя обновить новой оболочкой.

Свежий заголовок говорил правду только о себе

Обычная петля должна закончиться: TTL или hop count уменьшается при пересылке. В опасном условии RFC 1326 последующая инкапсуляция не переносила значение из прежнего заголовка. Старый счётчик мог сохраниться без искажения, но оказывался внутри полезной нагрузки. Внешняя сеть руководствовалась новым.

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

Перевод между протоколами тоже менял смысл. В RFC упомянуты X.25 и SMDS без hop count. Максимум AppleTalk составлял 16 переходов, тогда как IP мог выражать до 256. Сведение к меньшему диапазону останавливало часть петель, но могло создать чёрную дыру на законном IP-маршруте длиннее 16 переходов.

Полезные туннели образовали неполезную композицию

Простой туннель позволял пакету X пересечь сеть Y. Вход добавлял заголовок Y, выход снимал его, и X продолжал путь. Промежуточная сеть не обязана была понимать внутренний протокол.

RFC 1326 рассматривал среду, где обратная связь существовала в другом месте: X поверх Y и Y поверх X. В качестве примера названы IP поверх AppleTalk и AppleTalk поверх IP; рядом стояли CLNP, IPX, DECNET и собственные протоколы.

При временной петле X становился Y<X>. Вместо выхода он попадал к входу в сеть X и превращался в X<Y<X>>. После возврата к первой границе возникал Y<X<Y<X>>>.

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

MTU запустила размножение

Каждый оборот сначала добавлял байты одному пакету. Когда размер превысил Maximum Transmission Unit, пакет фрагментировался. Каждый фрагмент оставался в той же петле, получал новые заголовки и мог снова разделиться.

«Экспоненциальный взрыв» RFC 1326 — описание рекурсии, а не физического события и не установленной атаки. Документ имел статус Informational и прямо говорил, что вопросы безопасности не обсуждаются.

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

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

Просмотр внутрь заканчивался у неизвестного слоя

Сохранение hop count помогало лишь при совместимых полях. Другая идея предлагала заглянуть внутрь: если перед добавлением X маршрутизатор находил X уже внутри Y<X>, пакет можно было отбросить.

Но неизвестный заголовок останавливал разбор, шифрование скрывало структуру, а сетевой протокол мог находиться внутри транспортного. Более того, корректное вложение иногда законно содержало два одинаковых заголовка. Повторение давало сигнал, но не универсальное доказательство ошибки.

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

Отдельный лимит для отдельного действия

RFC 2003 позднее потребовал при IP-in-IP как части forwarding один раз уменьшать внутренний TTL и не инкапсулировать датаграмму с нулём. Определённые случаи совпадения источника с инкапсулятором или концом туннеля также отбрасывались.

RFC 2473 разделил для IPv6 исходный hop limit и Tunnel Encapsulation Limit. Первый учитывает пересылку исходного пакета, второй уменьшается при каждом вложенном туннеле. Ноль запрещает войти в новый туннель до выхода из текущего.

Это два разных измерения, потому что forwarding и добавление оболочки — разные события. RFC 2473 также отметил: фрагментация уже фрагментированного туннельного пакета удваивает число фрагментов. Более поздняя спецификация превратила предупреждение 1992 года в отдельную проверяемую границу.

Источники

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