Кратко

  • RFC 5320 превращает внешнюю фрагментацию IPv4 во вход контура: выход сообщает о ней, вход сверяет сообщение с окном SEAL_ID и меняет S_MSS следующего поколения сегментов.
  • Надёжная квитанция разделяет замысел пробы, 32- или 16-битный режим, наблюдение, обновление, сборку IPv4 и SEAL, передачу наверх и границу статуса Experimental.

Контур увидел помеху, а не весь путь

Туннель проходит по виртуальной топологии, тогда как физические звенья могут иметь разные MTU. SEAL обычно отправляет внешний IPv4 с DF=0. Маршрутизатор вправе его фрагментировать, выход сообщает событие, а вход уменьшает последующие сегменты.

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

Поэтому «отчёт принят» нельзя показывать как «путь проверен». Первое состояние может разрешить настройку. Второму нужны отдельные доказательства на каждой границе.

NAT сокращает договор идентичности

Обычный SEAL_ID имеет 32 бита: старшие 16 находятся в ID Extension, младшие — во внешнем IPv4 Identification. Вход случайно инициализирует значение для каждого выхода и увеличивает его по модулю 2^32.

IPv4 NAT может переписать внешнюю половину. Поэтому NAT-режим отслеживает только 16-битное расширение по модулю 2^16, а внешний Identification получает случайное значение. Склеивание полей после трансляции создаст личность, которую ни один конец не поддерживал.

Даже верное совпадение связывает ответ лишь с недавним состоянием. Оно не аутентифицирует маршрутизаторы, содержимое или итог пакета. В квитанции нужны режим, эпоха мягкого состояния и применённое окно.

S_MRU и S_MSS отвечают за разное

S_MRU, изначально не более 2 KB, ограничивает объём, который выход обязан собрать. S_MSS ограничивает сегмент и выводится из нижней IPv4 MTU, накладных расходов и границы, связанной с S_MRU/8.

Общее поле «MTU туннеля» уничтожит разницу между обязанностью реконструкции и размером отправки. Уменьшение S_MSS не меняет автоматически внутреннюю MTU. Большой нефрагментируемый внутренний пакет всё ещё может быть отброшен с PTB источнику.

Нужно отдельно хранить MTU интерфейса, расходы, S_MRU, значение и поколение S_MSS, внутреннюю длину, возможность фрагментации и событие, разрешившее переход.

Три разреза требуют трёх названий

SEAL делит пакет среднего слоя максимум на восемь неперекрывающихся сегментов. Непоследние равны, последний не больше; More Segments и трёхбитный номер описывают порядок. Выход восстанавливает пакет до передачи наверх.

Это не внутренняя фрагментация IPv4 и не фрагментация внешней оболочки маршрутизатором. У трёх действий разные исполнители, идентификаторы, точки сборки и способы исправления. Один счётчик fragments не объясняет решение.

Внешняя сборка IPv4 может пройти, а сборка SEAL — нет. После неё верхний протокол ещё может отказать. Успех одного этапа не заполняет следующий.

R и A задают разные вопросы

R=1 в нулевом сегменте просит отчёт о внешней фрагментации. A=1 просит подтверждение. Явная проба несёт данные либо является NULL с No Next Header; её SEAL_ID попадает в окно ожидающих отправок.

Если установлены оба бита и возникает фрагментация, выход отправляет один Fragmentation Needed, а не два независимых подтверждения. Исходную цель отправки необходимо сохранить.

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

Короткий первый фрагмент может обмануть

Неинкапсулированный ICMP — мягкая подсказка: его можно подделать, а цитаты может не хватить. Отчёт внутри SEAL, совпавший с текущим окном, связан лучше, но всё равно не обязательно раскрывает MTU ограничивающего звена.

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

Только первый применимый отчёт меняет S_MSS в поколении. Остальные сообщения старого состояния не являются новыми командами. Следующее решение ждёт трафика с новым значением.

Корреляция не равна аутентификации

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

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

Сборка вправе прекратиться

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

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

Experimental — институциональная граница

RFC 5320 вышел в феврале 2010 года как Experimental Independent Submission. Примечание IESG говорит, что обычного процесса консенсуса IETF не было. SEAL_PROTO, SEAL_PORT и SEAL_OPTION экспериментальны и не должны использоваться в поставляемых продуктах или обычных развёртываниях.

Поздние RFC об Identification, фрагментации и поиске MTU дают контекст, но не превращают SEAL задним числом в стандарт. Номер RFC удостоверяет документ, а не выдаёт производственное разрешение.

Квитанция решения

Хранятся время, вход, выход, режим 32/16 бит, эпоха, SEAL_ID, R, A, NULL или данные, размер, активное окно, S_MRU, значение и поколение S_MSS, наблюдаемый фрагмент, канал отчёта, разрешённое изменение и раздельные результаты обеих сборок и верхней передачи.

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

Источники