Может ли хост собрать IP дейтаграмму?

Question

[Black_Catty]

Нашел вот такое интересное упражнение из презентации по теме транспортного уровня :"Может ли получатель собрать IP дейтаграмму из этих четырех фрагментов из одинаковых заголовков?"

Comments

[Алан Гибизов]

См.п.3.1

Answer 1

[Mystray]

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

Раньше в RFC 1122(791) говорилось, что ОС может позволить протоколам высокого уровня сохранять один и тот же ID для повторно отправленных копий пакетов.

RFC 1122 states in Section 3.2.1.5 ("Identification: RFC 791
Section 3.2") that:
When sending an identical copy of an earlier datagram, a host MAY
optionally retain the same Identification field in the copy.

Однако, RFC 6864 запретил такое поведение:

o The IPv4 ID field is no longer permitted to be used for duplicate
detection. This applies to both atomic and non-atomic datagrams.
o Retransmitted non-atomic IPv4 datagrams are no longer permitted to
reuse the ID value.

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

Comments

[Black_Catty]

не совсем понял ваш ответ, фрагменты 3 и 4 будут выглядеть для получателя как 2 и1 фрагмент? И таким образом их можно собрать вместе?

[Mystray]

Black_Catty, нет, такого точно никогда не будет - ну посмотрите же как выглядит заголовок фрагментированного пакета, там все очевидно: есть поле ID, есть поле fragment offset. Поле ID совпадает у всех фрагментов одной датаграммы. Поле Offset обозначает, в какое место надо ткнуть пришедший фрагмент в итоге.
Если у пришедших фрагментов ID совпадают - хост пытается собрать их в единое целое. Если нет - они рассматриваются как не относящиесе друг к другу куски разных датаграм.
Суть в том, что этот ID назначает тот, кто занимается фрагментацией. При этом, если раньше назначение одного и того же ID допускалось, если происходит повторная отправка той же самой датаграммы(retransmit) то потом повторное назначение того же ID при фрагментации запретили, даже если это переотправка.
То есть, еще раз повторюсь - МОЖЕТ БЫТЬ.
Соберет, если ID будут совпадать, если отправитель будет следовать старым рекомедациям, и не соберет, если отправитель будет следовать новым правилам и ID будут разными.