Кратко
- Транзитный router не обязан собирать каждый проходящий IPv4 datagram. Если destination — сам router, он действует как host и применяет host reassembly requirements.
- Контекст может возникнуть от фрагмента с ненулевым offset. При истечении timer неполный datagram удаляется независимо от того, пришёл ли fragment zero.
- ICMP Time Exceeded Code 1 обязателен при наличии fragment zero. Поэтому локальный cleanup и видимая источнику ошибка принадлежат разным цепочкам доказательств.
Роль начинается с адресата
RFC 1812 проводит точную границу. Когда router пересылает packet, истечение TTL относится к forwarding и Code 0. Когда router собирает packet, предназначенный самому router, он действует как Internet host; к нему применяются требования host reassembly.
Это различие защищает анализ от простой ошибки: наличие fragments на интерфейсе не означает наличие reassembly buffer на каждом hop. Владельцем ожидания становится конечный IP module для данного destination. Именно там bytes занимают память, timer истекает и возникает вопрос о Code 1.
RFC 1812 также запрещает ICMP error в ответ на fragment, который не является первым. Ограничение имеет приоритет над другими требованиями к генерации ошибок. Устройство может видеть позднюю часть, но не превращает её автоматически в основание для внешнего заявления.
Состояние могло начаться не с нуля
RFC 791 выбирает reassembly buffer по source, destination, protocol и Identification. Fragment Offset определяет место данных. Offset zero означает первый фрагмент, MF zero — последний. Сеть не обещает порядок доставки.
Если первым наблюдался средний кусок, host всё равно выделял ресурсы. Последний кусок мог сообщить общую длину. Но header buffer заполнялся только при FO = 0, а доставка требовала непрерывных блоков от начала до известного конца.
Так возникает объект с владельцем и стоимостью, но без начала. Router в роли host знает достаточно, чтобы ждать и платить памятью. Он ещё не имеет целого packet и может не иметь материала для предусмотренного error quote.
Как TTL пытался управлять чужой памятью
Начальный пример RFC 791 ставил timer на минимум в 15 секунд и увеличивал его до remaining TTL нового fragment, если тот был больше. Спецификация прямо связывала data rate, время и объём buffer.
Но TTL уменьшался хотя бы на единицу за hop, даже если секунда не прошла. Он становился бюджетом пути, а не общим секундомером. Значение, сформированное forwarding nodes, плохо управляло памятью destination.
RFC 1122 потребовал reassembly timeout и рекомендовал фиксированное значение 60–120 секунд вместо remaining TTL. Малое значение может уничтожить законно задержанные fragments; большое связывает resources и увеличивает relevant lifetime Identification. Это рекомендация 1989 года, не утверждение о современных defaults.
Алгоритм дыр и сохранённый header
RFC 815 описал компактную работу с holes. Входящий fragment меняет список отсутствующих диапазонов; пустой список означает завершение. Метод не требует начала как первой arrival.
IPv4 options показывают предел. Часть options копируется, часть существует лишь в first fragment. До offset zero окончательная форма original header может оставаться неизвестной. Эффективная структура данных не восстанавливает отсутствующие факты.
RFC 1122 поэтому уточнил: first fragment header нужно сохранить для возможного ICMP Time Exceeded Reassembly Timeout. Это состояние для failure path. Если все bytes придут, header нужен целому datagram; если не придут, он нужен честной цитате о провале.
Что именно обещал Code 1
RFC 792 определил Type 11 Code 1. Ответ содержит original IP header и первые 64 data bits, чтобы source мог связать событие с процессом.
У позднего fragment есть IP header и source address. Иначе host не нашёл бы context. Но его payload начинается не там, где original datagram. RFC 792 ограничил ICMP errors случаями fragment zero и разрешил не отправлять Time Exceeded, если нулевой фрагмент недоступен.
RFC 1122 усилил результат: expired partial datagram должен быть удалён; Code 1 должен быть отправлен, если fragment zero получен. Cleanup обязателен для владельца памяти. Report обязателен при наличии исходного начала.
Timer сохраняет не только bytes
RFC 6864 связывает reassembly timeout с maximum datagram lifetime и периодом уникальности IPv4 Identification. Пока старые pieces остаются возможными, повтор той же комбинации может смешать поколения.
Поэтому длинное ожидание удерживает buffer и прежнее значение identity. Это не полный рассказ об ID field, а вторичный эффект решения destination о сроке state.
Ошибка может исчезнуть до обратного пути
Полученный Code 1 говорит: destination reassembler дождался expiry неполного набора, имел fragment zero, сформировал message, и message дошёл. Он не показывает место потери другого fragment.
Отсутствие Code 1 совместимо с отсутствующим zero fragment, rate limit, фильтром, потерей на return path или иной реализацией. Если считать только сообщения у source, в выборку чаще входят failures, сохранившие начало. Потеря начала делает систему тише, хотя memory state мог существовать.
Final fragment не заменяет zero. MF zero позволяет определить expected length и замкнуть диапазон holes, но не даёт original beginning для ICMP quote. Поля end_known и zero_received должны оставаться независимыми.
Code 1 не сообщает MTU и не указывает виновный link. RFC 1122 допускал его будущую роль в discovery procedure, но единичный timeout не доказывает узкое место. Нужны sent packet, path context и повторяемость.
Источники и пределы
- RFC 791 — Internet Protocol
- RFC 792 — Internet Control Message Protocol
- RFC 815 — IP Datagram Reassembly Algorithms
- RFC 1122 — Requirements for Internet Hosts — Communication Layers
- RFC 1812 — Requirements for IP Version 4 Routers
- RFC 6864 — Updated Specification of the IPv4 ID Field
RFC подтверждают правила и заявленные trade-offs. Они не измеряют текущие настройки, частоту fragmentation, доставку ICMP, фильтры или соответствие продуктов.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
