IP-фрагментация

Фрагментация IP — это процесс Интернет-протокола (IP), который разбивает пакеты на более мелкие части (фрагменты), так что полученные части могут проходить по каналу с меньшим максимальным блоком передачи (MTU), чем исходный размер пакета. Фрагменты повторно собираются принимающим хостом .

Детали механизма фрагментации, а также общий архитектурный подход к фрагментации различаются между IPv4 и IPv6 .

Процесс

RFC 791 описывает процедуру фрагментации IP, а также передачу и повторную сборку IP-пакетов. ^[1] RFC 815 описывает упрощенный алгоритм повторной сборки. ^[2] Поле идентификации вместе с внешним и локальным интернет-адресом и идентификатором протокола , а также поле смещения фрагмента вместе с «Не фрагментировать» и «Больше фрагментов» флагами в заголовке IP используются для фрагментации и повторной сборки IP-пакетов. ^[1]^: 24^[2]^: 9

Если принимающий хост получает фрагментированный IP-пакет, он должен собрать пакет заново и передать его на более высокий уровень протокола. Предполагается, что повторная сборка будет происходить на принимающем хосте, но на практике ее может выполнять промежуточный маршрутизатор, например, для трансляции сетевых адресов (NAT) может потребоваться повторная сборка фрагментов для трансляции потоков данных. ^[3]

Различия IPv4 и IPv6

В IPv4 маршрутизатор , который получает сетевой пакет , размер которого превышает MTU следующего перехода, имеет два варианта: отбросить пакет, если Не фрагментировать в заголовке пакета установлен бит флага « » (DF), и отправить протокол управляющих сообщений Интернета (ICMP). сообщение, указывающее на состояние «Необходима фрагментация» (Тип 3, Код 4), или фрагментируйте пакет и отправьте его по каналу с меньшим MTU. Хотя отправители могут создавать фрагментированные пакеты, маршрутизаторы IPv6 не имеют возможности дальнейшей фрагментации. Вместо этого сетевое оборудование должно доставлять любые пакеты IPv6 или фрагменты пакетов размером менее 1280 байт или равными, а хосты IPv6 должны определять оптимальный MTU посредством обнаружения MTU пути перед отправкой пакетов.

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

В IPv4 хосты должны приложить все усилия для повторной сборки фрагментированных IP-пакетов с общим размером до 576 байт. Они также могут попытаться собрать фрагментированные IP-пакеты размером более 576 байт, но им также разрешено молча отбрасывать такие более крупные пакеты. Приложениям рекомендуется воздерживаться от отправки пакетов размером более 576 байт, если они заранее не знают, что удаленный хост способен их принять или собрать заново. ^[1]^: 12

В IPv6 хосты должны приложить все усилия для повторной сборки фрагментированных пакетов с общим повторно собранным размером до 1500 байт, что превышает минимальный размер MTU IPv6, равный 1280 байт. ^[4] Фрагментированные пакеты с общим повторно собранным размером более 1500 байт могут быть автоматически отброшены. Приложения, использующие фрагментацию IPv6 для преодоления ограничения MTU пути, должны явно фрагментировать пакет в точке происхождения; однако им не следует пытаться отправлять фрагментированные пакеты общим размером более 1500 байт, если они заранее не знают, что удаленный хост способен к повторной сборке.

Влияние на сетевую переадресацию

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

Фрагментация IP может вызвать чрезмерную повторную передачу, когда фрагменты теряют пакеты , и надежные протоколы, такие как TCP, должны повторно передавать все фрагменты, чтобы восстановиться после потери одного фрагмента. ^[5] Таким образом, отправители обычно используют два подхода для определения размера IP-пакетов для отправки по сети. Первый заключается в отправке хостом-отправителем IP-пакета размером, равным MTU первого перехода пары источник-назначение. Второй — запустить алгоритм Path MTU Discovery. ^[6] для определения MTU пути между двумя IP-хостами, чтобы избежать фрагментации IP.

По состоянию на 2020 год ^[update]Фрагментация IP считается хрупкой и часто нежелательной из-за ее влияния на безопасность. ^[7]

См. также

IPv4 § Фрагментация и повторная сборка
Пакет IPv6 § Фрагментация
Атака фрагментации IP
Блок данных протокола и блок служебных данных
Сегментация и повторная сборка – размещение данных в ячейках сети банкоматов.

Ссылки

^ Перейти обратно: ^а ^б ^с Интернет-протокол , Институт информационных наук, сентябрь 1981 г., RFC 791.
^ Перейти обратно: ^а ^б Дэвид Д. Кларк (июль 1982 г.), Алгоритмы повторной сборки IP-дейтаграмм , RFC 815
^ Хейн, Тони Л. (ноябрь 2000 г.), Архитектурные последствия NAT , RFC 2993.
^ С. Диринг ; Р. Хинден (декабрь 1998 г.), Спецификация интернет-протокола версии 6 (IPv6) , RFC 2460.
^ Кристофер А. Кент, Джеффри С. Могул. «Фрагментация считается вредной» (PDF) .
^ Диринг, Стив Э.; Могул, Джеффри (ноябрь 1990 г.), Path MTU Discovery , RFC 1191
^ Фрагментация IP считается хрупкой . Сентябрь 2020 г. doi : 10.17487/RFC8900 . РФК 8900 .

Внешние ссылки

[RFC791-1] Перейти обратно: ^а ^б ^с Интернет-протокол , Институт информационных наук, сентябрь 1981 г., RFC 791.

[RFC815-2] Перейти обратно: ^а ^б Дэвид Д. Кларк (июль 1982 г.), Алгоритмы повторной сборки IP-дейтаграмм , RFC 815

[3] Хейн, Тони Л. (ноябрь 2000 г.), Архитектурные последствия NAT , RFC 2993.

[rfc2460-4] С. Диринг ; Р. Хинден (декабрь 1998 г.), Спецификация интернет-протокола версии 6 (IPv6) , RFC 2460.

[5] Кристофер А. Кент, Джеффри С. Могул. «Фрагментация считается вредной» (PDF) .

[6] Диринг, Стив Э.; Могул, Джеффри (ноябрь 1990 г.), Path MTU Discovery , RFC 1191

[7] Фрагментация IP считается хрупкой . Сентябрь 2020 г. doi : 10.17487/RFC8900 . РФК 8900 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]