Переупорядочивает ли хост фрагментированные IP-пакеты, полученные не по порядку?

Question

Узел A отправляет 1400-байтовый IP-пакет узлу B по каналу Ethernet и PPP. Канал PPP имеет MTU 532 байта, что означает, что IP-пакет будет фрагментирован на 3 меньших пакета.

Фрагмент 1 получен первым. Он имеет уникальный идентификатор и установлен битовый флаг М, указывающий, что есть еще фрагменты. Однако следующий фрагмент 3 принимается из-за некоторого переупорядочения в сети. Этот фрагмент имеет тот же идентификатор, что и фрагмент 1, но бит М не установлен, потому что это последний фрагмент. Фрагмент 2 получен вскоре после.

Что будет делать принимающий хост?

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

2. Будет ли принимающий хост повторно собрать пакет (обе контрольные суммы заголовка совпадают) и передать его на более высокий уровень (где он не сможет выполнить контрольную сумму IP для данных при использовании UDP/TCP).

3. Будет ли принимающий хост отбрасывать все фрагменты для этого идентификатора.

Answer 1

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

RFC 791 в разделе 3.2 определяет, что:

If the timer runs out, the all reassembly resources for this buffer identifier are released. The initial setting of the timer is a lower bound on the reassembly waiting time. This is because the waiting time will be increased if the Time to Live in the arriving fragment is greater than the current timer value but will not be decreased if it is less. The maximum this timer value could reach is the maximum time to live (approximately 4.25 minutes). The current recommendation for the initial timer setting is 15 seconds.

Это время повторной сборки для IPv4 и IPv6 в Linux составляет 30 секунд, а для Windows (Vista, 2008, 7 и 2008 R2) - 60 секунд в соответствии с разделом 4.5 RFC 2460:

If insufficient fragments are received to complete reassembly of a packet within 60 seconds of the reception of the first-arriving fragment of that packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded.