Кратко

  • RFC 1241 помещал неизменённый Clear Datagram за внешним IP-заголовком и восьмиоктетным служебным заголовком, а затем проводил его через отдельное Encapsulation Space.
  • 32-битный Flow ID имел смысл только на конкретном инкапсуляторе или декапсуляторе; таблицы и обратные соответствия обслуживал не определённый документом верхний уровень.
  • ICMP из туннеля цитировал внешний IP и весь служебный заголовок, но ни одного байта Clear Datagram. Сообщение о сбое могло вернуться без исходного контекста.

Невидимый маршрут оставлял видимую обязанность

RFC 1241 Роберта Вудберна и Дэвида Миллса вышел в июле 1991 года как экспериментальный протокол. Документ называл исходную IP-дейтаграмму Clear Datagram в User Space. Инкапсуляторы и декапсуляторы находились в другом адресном и маршрутном мире — Encapsulation Space.

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

Незнание источника не устраняло знание системы. Инкапсулятор выбирал, какой Clear Header направить по какому пути и к какому декапсулятору. Этот путь RFC 1241 называл Flow, или туннелем. Он мог состоять из нескольких пар устройств, не показывая шлюзы User Space, через которые фактически проходил пакет.

Flow ID не был глобальным именем. 32-битное значение было уникально только для одного устройства. На следующем узле тот же Flow мог называться иначе. Чтобы вернуть ошибку, таблица хранила адрес предыдущего инкапсулятора и номер, понятный именно ему. Обратный путь состоял из последовательных локальных переводов.

Как создавать и обновлять таблицы, протокол не устанавливал. Этим занималась сущность верхнего уровня; для эксперимента могли хватить ASCII-файлы. Поэтому найденная локальная запись доказывала только наличие записи, но не её свежесть, согласованность с соседом или работоспособность обратной цепочки.

Внутренние байты не менялись, а сетевой объект становился больше

Оболочка добавляла новый IP-заголовок и восемь октетов с версией, типом сообщения, кодом причины, контрольной суммой и Flow ID. За ними шёл исходный Clear Datagram. Внешними источником и назначением становились инкапсулятор и декапсулятор. Приоритет и качество обслуживания могли копироваться, а timestamp, record route и source route — нет.

Внутренний TTL не переносился во внешний заголовок, но уменьшался перед инкапсуляцией. Если декапсулятор обходил обычную IP-пересылку с помощью Flow ID, он сам должен был обработать TTL перед следующим этапом.

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

Фрагменты влияли и на классификацию. Таблица могла выбирать Flow по портам TCP или соединению. Но TCP-заголовок есть только в первом IP-фрагменте. Правило по порту могло распознать первый фрагмент и не распознать остальные. Это граница метода, а не утверждение о конкретной аварии.

RFC 1191 уже описывал Path MTU Discovery через DF и ICMP «fragmentation needed». Во внешнем пространстве источником был инкапсулятор, поэтому маршрутизатор правильно возвращал ICMP ему. Превратить эту информацию в сигнал для внутреннего источника должен был уже туннельный слой.

Шестьдесят четыре бита закончились до внутреннего пакета

По RFC 792 ошибка ICMP включала вызвавший её IP-заголовок и как минимум 64 следующих бита. В RFC 1241 эти 64 бита полностью занимал восьмиоктетный заголовок протокола инкапсуляции. Цитата не захватывала Clear Datagram.

Инкапсулятор видел внешнее назначение и Flow ID, но не внутренний IP-источник и не порты TCP. Несколько разных Clear Headers могли вести в один Flow, поэтому обратить идентификатор и точно восстановить исходный заголовок было невозможно. Ошибка описывала внешний путь, но не называла однозначно внутренний обмен.

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

Компромисс переносил уведомление на будущее. Полученный ICMP отмечал Flow, а следующий подходящий Clear Datagram заставлял инкапсулятор создать новое сообщение его источнику. Следующий пакет становился поводом сообщить состояние, узнанное на предыдущем. Это не индивидуальная квитанция, и документ считал подход, вероятно, безопасным лишь для некоторых типов ошибок.

Позднейшие документы сохранили проблему в поле зрения

Они не доказывают массовое внедрение RFC 1241. RFC 1853 даёт более узкую документальную связь: он отличает простой IP-in-IP без специального промежуточного заголовка от протокола 98 RFC 1241 и указывает, что заимствовал часть структуры и текста.

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

RFC 4459 позже назвал размер пакетов в сетевых туннелях распространённой и нетривиальной задачей. Фрагментировать снаружи, сообщать меньший MTU, оставлять запас или фрагментировать внутри — разные способы распределить состояние, расходы и доказательства.

RFC 1241 подтверждает предложенный формат, локальную природу ID, обратной перевод и потерю внутреннего заголовка в обычной ICMP-цитате. Он не подтверждает конкретную реализацию, доставку или получение эквивалентной ошибки источником. Для этого нужны связанная запись входного Clear Header, версия таблицы, внешняя оболочка, наблюдение декапсуляции и точные байты ICMP. Прозрачность не заменяет отсутствующее звено.

Источники