Кратко

  • RFC 2004 заменяет исходные Protocol и адрес назначения, а при необходимости — и адрес источника, затем добавляет не второй полный IPv4-заголовок, а только восьми- или двенадцатиоктетный Minimal Forwarding Header.
  • При S=0 исходный адрес источника отсутствует, потому что точка входа должна сама быть источником датаграммы. Это условная экономия, а не удостоверение личности отправителя.
  • Контрольная сумма служебной вставки покрывает только её саму. Успешное восстановление не доказывает полномочия туннеля, целостность маршрута, подлинность источника или доставку приложению.

Вместо второго конверта изменили первую карточку

RFC 2004 сокращает накладные расходы обычного IP-in-IP. Полный внешний IPv4-заголовок потребовал бы как минимум двадцать октетов. Минимальная инкапсуляция оставляет полезную нагрузку на месте и заставляет исходный IP-заголовок временно описывать туннельный участок.

В нём Protocol становится равным 55, адрес назначения меняется на выход туннеля. Если точка входа пересылает чужую датаграмму, она заменяет и источник собственным адресом. Total Length увеличивается на размер вставки, после чего пересчитывается контрольная сумма IP-заголовка. Между этим изменённым заголовком и неизменной полезной нагрузкой помещается Minimal Forwarding Header.

Короткая форма добавляет восемь октетов, длинная — двенадцать. По сравнению с минимальным двадцатиоктетным внешним заголовком экономия составляет двенадцать или восемь октетов. Однако отличие от RFC 2003 не сводится к длине. Полная инкапсуляция сохраняет внутренний заголовок как самостоятельную запись. RFC 2004 оставляет только несколько значений и алгоритм их обратной подстановки.

Отсутствующие четыре октета означают утверждение о равенстве

В служебной вставке всегда находятся исходные Protocol и адрес назначения. Исходный источник присутствует лишь при S=1. Эта длинная форма нужна, когда вход заменил источник: выход читает сохранённые четыре октета и возвращает прежний адрес.

При S=0 поля источника нет. Это допустимо только в предусмотренном стандартом случае: вход туннеля уже являлся исходным источником датаграммы, поэтому видимый в изменённом IP-заголовке адрес годится и после выхода. Протокол не сохраняет копию значения, которое считает неизменным.

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

Контрольные суммы не объединяют разные области доказательства

Minimal Forwarding Header содержит 16-битную контрольную сумму в дополнительном коде до единицы. Она вычисляется лишь по восьми или двенадцати октетам самой вставки, причём её поле на время вычисления считается нулевым. Изменённый IPv4-заголовок и полезная нагрузка не входят в область защиты. Корректная сумма подтверждает ограниченную вещь: сохранённые Protocol, биты и адресные слова согласованы внутри этой вставки в момент проверки.

У туннельного IPv4-заголовка есть собственная контрольная сумма, пересчитанная для текущих адресов, Protocol и Total Length. На выходе вставку удаляют, длину уменьшают, поля восстанавливают и контрольную сумму IP снова вычисляют заново. Это разные состояния и разные проверки. Ни одна сумма не является подписью, не разрешает туннель и не защищает полезную нагрузку сквозным образом.

Восстановить поля — не значит вернуть время назад

Результат декапсуляции не является побайтовой фотографией входа. Прежняя IP-контрольная сумма вообще не сохранялась. Кроме того, исходная TTL продолжает жить в том же изменённом заголовке. Обычная пересылка уменьшает её на каждом переходе внутри туннеля, поэтому такой туннель может быть виден traceroute. Выход не возвращает раннее значение TTL.

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

Уже фрагментированный пакет не помещается в модель

Минимальную инкапсуляцию запрещено применять к исходной датаграмме, которая уже фрагментирована: в компактной вставке нет места для сохранения существующей информации о фрагментации. Это условие на входе, а не вечный запрет фрагментации. После инкапсуляции работают обычные правила IPv4 об опциях и фрагментах, если DF не запрещает их; вопросы MTU связывают механизм с RFC 1191.

Правила против маршрутных петель, обработку ICMP и мягкое состояние RFC 2004 заимствует у RFC 2003. Раздел безопасности ещё осторожнее: документ не решает вопросы безопасности, а лишь считает соображения в целом сходными. Поэтому Protocol 55, правильные длины и суммы нельзя превращать в обещание безопасности, которого стандарт не давал.

Документ появился рядом с RFC 2002 как возможный способ снизить накладные расходы Mobile IP. Запись mobility binding и наблюдение инкапсулированного пакета всё равно остаются разными доказательствами. RFC Editor и IETF Datatracker подтверждают существование и статус Proposed Standard, но не факт развёртывания. В терминах эссе Lu Heng Running-Code Primacy текст стандарта описывает ожидаемое поведение, а работающая система требует операционных следов. Minimum Initial Specification и Reality Layers проводят ту же границу: минимальная общая форма способна сделать восстановление однозначным, но не превращает сопутствующие допущения в факты.

Источники