Кратко

  • Старший бит типа опции IPv4 сообщал фрагментатору, должна ли опция остаться только в первом фрагменте или появиться во всех.
  • Фрагментация порождала производные, а не одинаковые заголовки: набор опций, IHL, Total Length, Fragment Offset, MF и контрольная сумма могли различаться по правилам.
  • Copy 1 передавал контекст обработки, но не гарантировал доставку, подлинность или неизменность копии. Полный набор некопируемых опций оставался у фрагмента с нулевым смещением.

Часы и смещение давали разные ответы на вопрос «что было первым»

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

RFC 815 предупреждает: до прихода первого фрагмента получатель может не знать окончательный размер заголовка. Фрагмент с ненулевым смещением законно опускает опции, которые не должны копироваться, и потому показывает меньший IHL.

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

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

Правило наследования помещалось в одном бите

RFC 791 разбивает октет типа опции на Copy-бит, два бита Class и пять битов Number. Ноль означает копирование только в первый фрагмент. Единица — копирование во все фрагменты.

Loose Source and Record Route имеет тип 131, поэтому её старший бит равен единице. Record Route имеет тип 7 и старший бит ноль. Если исходный заголовок содержит обе, фрагмент со смещением ноль сохраняет обе опции, а последующие — только тип 131.

Strict Source and Record Route типа 137 и Stream Identifier типа 136 также имеют Copy 1. Timestamp типа 68 имеет Copy 0. Это не рейтинг важности. Бит распределяет, какой контекст потребуется каждому самостоятельно маршрутизируемому производному объекту.

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

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

RFC 760 уже в январе 1980 года различал опции, копируемые в каждый фрагмент, и опции только первого фрагмента. Процедура требовала выборочно копировать Internet Header при создании следующей части.

RFC 791 закрепил механизм в формате типа. Первый фрагмент строился на исходном заголовке. Для последующих удалялись некопируемые опции. Это меняло Internet Header Length. Размер данных определял Total Length, позиция — Fragment Offset, наличие продолжения — More Fragments. После правки заголовка заново вычислялась Header Checksum.

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

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

Ноль не означал ненужность, единица — защиту

Record Route и Timestamp не становятся несущественными из-за Copy 0. Полный исходный набор остаётся во фрагменте ноль. Бит отвечает за размещение после разделения, а не за ценность информации.

Copy 1 также не обещает приоритета, надёжности, шифрования, аутентификации или подтверждённой доставки. Историческая Basic Security Option типа 130 имела Copy 1, но её политика меток не создавалась этим битом.

Реестр параметров IPv4 IANA показывает Copy, Class, Number, Value, Name и Reference. Он надёжно связывает номер с документом. Он не измеряет современное распространение, не подтверждает поддержку продукта и не доказывает обработку на конкретном маршруте.

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

Копии могли записать разные маршруты

Сразу после фрагментации копии одной опции имеют общее происхождение. Затем фрагменты могут пройти разными путями. RFC 815 отмечает, что source-and-record-route-опция способна получить разные записи от разных маршрутизаторов.

Поэтому «скопировано во все» не означает «пришло одинаковым». Copy-бит сохраняет возможность и обязанность обработки в каждой части, но не замораживает поля, которые разрешено изменять по дороге.

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

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

Полная проверка зависела от полномочного IHL

RFC 6274 использует тот же предел при проверке безопасности. Чтобы удостовериться, что собранный пакет действительно вмещает заявленный транспортный заголовок, нужен IHL фрагмента с нулевым смещением. У более позднего фрагмента он может быть меньше из-за Copy-0-опций.

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

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

Конец списка и выравнивание были частью преобразования

End of Option List и No Operation завершают и выравнивают область опций. Удалив из последующего заголовка некопируемые элементы, фрагментатор может заново оформить конец и заполнение, чтобы сохранить 32-битную границу.

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

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

Минимальная общая спецификация остаётся строгой. Она сокращает число глобальных решений, а не точность проверяемых инвариантов.

Позднейшая хрупкость не превращает механизм в фикцию

RFC 8900 повторяет: все опции IPv4 присутствуют в первом фрагменте, а в последующих — только опции Copy 1. Документ также разбирает потери, middlebox-устройства, фильтры без транспортного заголовка и ограниченные ресурсы сборки.

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

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

Получивший нож не получал власть над смыслом

В IPv4 фрагментатором может быть источник или маршрутизатор — в зависимости от MTU, пути и Don’t Fragment. Начальная сцена с маршрутизатором лишь подчёркивает промежуточное преобразование.

Полномочие в любом случае узкое: разделить данные, установить поля сборки, выбрать опции по Copy, закрыть заголовок и пересчитать сумму. Оно не включает право объявить Copy-0-состояние бессмысленным, заверить истинность Copy-1-опции или гарантировать её доставку.

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

Расследование должно сохранять законные различия

Полезная цепочка связывает источник, назначение, протокол, Identification, Offset, MF, IHL, типы опций, Copy-значения и порядок прихода. Она ищет конкретные нарушения: Copy 0 в ненулевой части, пропавший Copy 1, обрезанную опцию, неверное выравнивание или неповторённую предварительную проверку.

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

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

Источники и границы доказательства

Материал опирается на RFC 760, RFC 791, RFC 815, RFC 1122, RFC 1812, RFC 6274, RFC 8900, RFC 8200 и реестр IANA. Они устанавливают спецификации и ограниченные операционные следствия, но не современную распространённость, соответствие продуктов, частоту атак или судьбу всех реальных фрагментов.