Кратко

  • RFC 2003 помещает целую IPv4-дейтаграмму за новым IPv4-заголовком: внешние адреса называют вход и выход туннеля, внутренние сохраняют исходные концы связи.
  • При пересылке на входе внутренний TTL уменьшается до инкапсуляции, а внешний TTL выбирается независимо для пути к выходу.
  • DF, MTU, внешняя фрагментация, сборка и перевод ICMP распределяют обязанности; само значение 4 сообщает лишь тип содержимого.

Модель пути не становится историей пакета

RFC 2003 добавляет внешний IPv4-заголовок, не заменяя исходную дейтаграмму. Внешний источник — адрес инкапсулятора, внешнее назначение — адрес декапсулятора. Внутренние адреса остаются у исходного отправителя и получателя. До выхода маршрутизация смотрит на внешний адрес, после снятия оболочки — снова на внутренний.

Значение 4 в поле Protocol означает, что далее начинается ещё один IPv4-заголовок. Как показывает RFC 1853, отдельная промежуточная шапка не нужна. Это точное описание формата, но не подпись внутреннего источника, не правило допуска и не подтверждение доставки.

Мягкое состояние возникает из нехватки цитаты

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

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

Разные ICMP имеют разную судьбу. Protocol Unreachable превращается в недоступность сети или узла: внутренний отправитель протокол 4 не выбирал. Port Unreachable не пересылается, поскольку у внешнего IP нет порта. Datagram Too Big переслать нужно. Tunnel Time Exceeded становится Host Unreachable. Parameter Problem относится к исходному пакету лишь тогда, когда указатель попадает в поле, скопированное изнутри.

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

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

RFC 1191 определяет сигнал: маршрутизатор, не способный передать слишком большой DF-пакет, возвращает Destination Unreachable, code 4, и MTU следующего перехода. Внутри туннеля сообщение идёт внешнему источнику — входу. Полезный MTU для исходного отправителя уменьшается на размер добавленного заголовка.

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

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

Внутренний и внешний TTL идут разными часами

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

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

Правило 1996 года читается вместе с обновлениями

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

RFC 6864 обновил смысл внешнего IPv4 Identification. Требование уникальности связано с возможной или фактической фрагментацией; это поле не служит универсальным серийным номером. IETF Datatracker фиксирует статус Proposed Standard и оба обновления, но не подтверждает поведение конкретной реализации.

Доказательство должно пройти обе границы

RFC предупреждает: оболочка убирает исходные адреса, протокол и порты из привычных позиций для фильтра. Доверие внешнему источнику не аутентифицирует внутренний. Политике допуска может потребоваться анализ обоих уровней.

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

Running-Code Primacy не позволяет принять публикацию за исполнение. Minimum Initial Specification оставляет будущие локальные решения открытыми. Reality Layers разделяет знак, намерение, наблюдение и итог. Протокол 4 говорит, какой конверт открыть; судьбу письма доказывает только связанная цепочка наблюдений.

Источники