Кратко

  • RFC 7112 требует, чтобы IPv6-фрагмент с Fragment Offset, равным нулю, содержал полную цепочку от базового IPv6-заголовка до первого заголовка верхнего уровня. Без сохранения состояния фильтр может увидеть протокол и доступные порты до принятия решения.
  • Полнота первого фрагмента не равна полноте дейтаграммы. Построение у источника, MTU пути, настройка устройства, ICMPv6 Type 4 Code 3, последующие смещения, перекрытия, тайм-аут, сборка и результат приложения нуждаются в отдельных записях.

Решающее поле осталось во второй части

Между базовым заголовком IPv6 и TCP или UDP может располагаться последовательность заголовков расширения. Каждый Next Header указывает тип следующего элемента. При длинной цепочке граница фрагмента способна пройти до транспортного заголовка.

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

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

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

«Вся цепочка» не означает всю нагрузку

Цепочка начинается с исходного IPv6-заголовка, проходит через ноль или несколько заголовков расширения и заканчивается первым заголовком верхнего уровня. Обычно это TCP, UDP или ICMPv6. При туннелировании IPv6 в IPv6 второй IPv6-заголовок считается таким окончанием для определения RFC 7112. ESP также завершает цепочку; при отсутствии следующего протокола её заканчивает No Next Header.

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

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

Механизм даёт достаточно сведений для одного вопроса. Остальные вопросы требуют собственных сигналов.

Нулевое смещение — координата, не удостоверение

RFC определяет первый фрагмент как фрагмент со смещением ноль. Условие читается локально и однозначно: не нужен реестр и не требуется дождаться полной сборки.

Но злоумышленник тоже может выставить ноль и построить правильные заголовки. IPv6-адрес источника и Fragment Identification не являются криптографической подписью. Фильтр узнаёт положение и структуру, а не личность.

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

Так выглядит тонкая общая спецификация: единое проверяемое условие без передачи локальной власти IETF, автору или производителю оборудования.

Разные участники получают разные глаголы

Для источника правило жёсткое: если хост фрагментирует, он должен включить полную цепочку в первый фрагмент.

Хост-получатель неполного первого фрагмента должен, в рекомендательном смысле RFC, отбросить его и отправить ICMPv6-ошибку с учётом общих ограничений. Ради обратной совместимости реализация может иметь настройку приёма.

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

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

Code 3 превращает причину в сообщение

Если узел отбрасывает по этой причине и посылает диагностику, используется ICMPv6 Parameter Problem: Type 4, Code 3, Pointer равен нулю. В реестре IANA код означает неполную IPv6-цепочку в первом фрагменте.

Специальное значение полезно как квитанция. Разработчик видит процитированный пакет. Оператор сопоставляет рост сообщений с выпуском ОС, изменением туннеля или новым порядком расширений. Тестовая лаборатория создаёт пару полных и неполных вариантов.

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

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

MTU входит в причинную цепочку

Раз заголовки должны поместиться в первый фрагмент, их длина ограничена MTU пути. RFC 7112 требует от источника без механизма обнаружения MTU держать цепочку в пределах 1280 байт.

Нарушение не обязательно означает атаку. Новая инкапсуляция могла уменьшить эффективный MTU. Кэш пути мог устареть. Стек мог построить необычно длинную последовательность расширений.

Нужен MTU, известный источнику в момент отправки, а не только значение, измеренное после инцидента. Для туннелей важно знать слой фрагментации и слой, на котором пакет увидел фильтр.

Иначе операционная ошибка классифицируется как злоумышленное уклонение только потому, что счётчик стоит в системе безопасности.

Восемь независимых строк

Первая строка описывает пакет: источник, назначение, идентификатор, offset, M, последовательность расширений, достигнутый заголовок верхнего уровня и длину цепочки. Вторая фиксирует точку захвата.

Третья хранит сведения о MTU. Четвёртая — реализацию и версию источника. Пятая — устройство обработки, интерфейс, версию парсера, правило, режим совместимости и verdict. Шестая — генерацию, ограничение и наблюдение Code 3.

Седьмая относится к сборке: offsets следующих частей, длины, дубликаты, перекрытия, порядок и тайм-аут. Восьмая сообщает о TCP и приложении.

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

Единая метка IPv6 fragment blocked выбрасывает именно те различия, ради которых условие стало проверяемым.

Допуск не заменяет сборку

RFC 8200 включил правило в базовую спецификацию IPv6. Он отдельно показывает заголовки, присутствующие в каждом фрагменте, Fragment Header, размещаемые в первом дополнительные расширения и Upper-Layer Header, а затем данные.

В конечном узле работает другая машина. Она группирует части по источнику, назначению и Fragment Identification, вычисляет позиции по смещениям и длинам. Через 60 секунд неполная сборка прекращается. Неверные длины вызывают ошибки. Перекрытие требует отбросить всю дейтаграмму. Точные дубликаты могут удаляться отдельно.

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

Firewall может отбросить offset ноль и всё же переслать более поздние части. Без первой части назначение не восстановит исходный пакет. Поэтому счётчик пересланных частей нельзя называть доказательством допуска дейтаграммы.

Три вывода должны остаться раздельными: проверка цепочки, сборка, сервис.

Атомарный фрагмент не ждёт продолжения

RFC 6946, написанный Fernando Gont, рассматривает пакет с Fragment Header, у которого и offset, и M равны нулю. Это атомарный фрагмент — уже полная дейтаграмма.

Некоторые реализации всё равно смешивали его в очереди сборки с частями, имеющими ту же тройку источника, назначения и идентификатора. Такое смешение создавало атаку. RFC 6946 предписал обрабатывать атомарные фрагменты независимо; RFC 8200 сохранил правило.

Это не другой вариант RFC 7112. Неполный первый фрагмент, полный атомарный пакет и перекрывающиеся части — разные состояния и разные исправления.

Если телеметрия сохраняет лишь факт наличия Fragment Header, она уничтожает сведения offset, M, идентификатор и окончание цепочки, которые уже были на проводе.

Документ изменился — оборудование ещё нужно проверить

RFC 7112 обновил RFC 2460 в 2014 году. RFC 8200 заменил прежний стандарт в 2017-м и включил требование: расширения после Fragment Header и Upper-Layer Header должны находиться в первой части. При отсутствии рекомендуется отбрасывание и Code 3.

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

Эта история подтверждает эволюцию спецификации. Она не проверяет глубину парсинга ASIC, выключение старого режима или конкретную генерацию ICMPv6.

Локальное принятие доказывают сконструированные тесты, захват до и после устройства, счётчики, версионированные правила и результат сервиса. Дата RFC не равна дате внедрения.

Документированная роль Fernando Gont

Fernando Gont указан в RFC 7112 вместе с Vishwas Manral и Ron Bonica. Standards Track отражает проверку и консенсус IETF. Это коллективный документ, а не единоличное изобретение или мандат автора управлять чужими сетями.

Действующий профиль IETF перечисляет 40 RFC и работу в области безопасности протоколов. RFC 6946 показывает родственный метод: разделить состояния, которые смешивали реализации, и дать им локально читаемые признаки.

В RFC 7112 первый фрагмент обязан раскрыть нужную границу. В RFC 6946 атомарный пакет остаётся вне чужого состояния сборки. Спецификация определяет функцию, оператор выбирает локальное действие, назначение собирает, приложение показывает результат.

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

Источники