Источник может отправить два фрагментированных пакета IP одновременно?
Я разрабатываю приложение, которое делает NAT между виртуальным интерфейсом TAP и физическим интерфейсом, и я не уверен, сколько буфер должен я выделять для фрагментации IP.
Согласно Википедии максимальное значение для "Смещения Фрагмента" ограничивается 8 189, но действительно ли возможно, что источник отправляет 2 или больше фрагментированных пакета одновременно? Или это отправит их последовательно (т.е. не отправляет другой фрагментированный пакет, пока это не заканчивает первый)?
Смещение фрагмента
Смещение фрагмента - это 13-битное поле, и если интерпретировать эти биты как беззнаковое целое число, то максимальное значение будет 8191. Но на самом деле это подсчет кратных 8 байт, поэтому имеет смысл сказать, что значения идут от 0 до 65528 с шагом 8.
То, что именно является максимальным допустимым значением самого этого поля, не имеет особого значения. Важным является максимальное значение суммы полей смещения и длины. Если эта сумма слишком велика, то пакет недействителен. Даже если каждое поле по отдельности находится в пределах допустимого диапазона, их сумма все равно может превышать допустимые значения. Невозможность проверки суммы при получении может привести к недостаткам безопасности.
Пакет, использующий этот конкретный недостаток безопасности, был назван "ping-of-death" (квитанция смерти). Что несколько вводит в заблуждение, потому что это не имеет никакого отношения к пингу, и привело к распространенному ошибочному мнению, что пакеты ping опасны.
Все вышесказанное относится к смещению фрагментов, упомянутому в вашем вопросе, но никак не связано с вашим фактическим вопросом.
Поле IP ID
Вы спрашиваете, может ли источник посылать два фрагментированных пакета одновременно. Безусловно, в соответствии со стандартом допускается интерлевация двух фрагментированных пакетов у отправителя. Однако это редко имеет смысл. Однако, нельзя делать никаких предположений на этот счет.
В случае использования NAT, возможно, что два пакета, которые были отправлены с двух разных хостов с разными IP-адресами, будут иметь один и тот же IP источника, как только они достигнут места назначения. И как только поток фрагментов от двух разных источников встретится, они могут оказаться чередующимися.
Даже если такой NAT не задействован, все равно возможно, что пакеты будут переупорядочены сетью (например, если они будут маршрутизированы по разным путям). Таким образом, они могут в конечном итоге перемещаться, как только достигнут адресата по ряду причин.
Для того, чтобы убедиться, что получатель может правильно собрать пакеты, в заголовке есть поле IP ID (которое составляет 16 бит на IPv4 и 32 бита на IPv6). Для повторной сборки приемник должен учитывать IP-адрес источника, IP-адрес назначения и IP-идентификатор. Этого в принципе достаточно для сборки полезного груза, который перемещался в пути.
К сожалению, в случае NAT все не так просто. Он действителен для двух разных хостов с разными IP, которые одновременно посылают по одному пакету, каждый из которых имеет один и тот же IP ID. (Очевидно, это должно быть разрешено, потому что ни один из них не может знать о том, что пакет посылается другим). Однако, если IP-адрес источника пакетов изменен NAT, так что теперь они имеют идентичный IP-адрес источника, они могут больше не быть различимы.
Исправление этой проблемы в NAT не очень практично. Поэтому нет ничего необычного в том, что NAT просто игнорирует ее и надеется на лучшее. Это означает, что существует риск того, что фрагментированные пакеты, посылаемые через NAT, будут собраны неправильно, и, возможно, произойдет утечка данных из одного соединения в другое.
Этот риск значительно меньше для IPv6, так как поле IP ID больше. Он также меньше, потому что с IPv6 вы не используете NAT (если только вам не нравится отлаживать проблемы, введенные NAT)
.