Я работал над проектом, который включает в себя разработку приложения с использованием java-сокетов. Однако, читая некоторые основы и новую парадигму IPv6, которые побудили меня задать ниже вопрос,
Каковы преимущества удаления фрагментации из IPv6?
Было бы полезно, если бы кто-нибудь мог дать мне понять, почему?
Я исследовал в Интернете, но не нашел никакого полезного описания.
Распространенным заблуждением является то, что фрагментации IPv6 нет, потому что в заголовке IPv6 нет поля фрагмента-смещения, которое есть в IPv4; однако это не совсем точно. IPv6 не позволяет маршрутизаторам фрагментировать пакеты; однако конечные узлы могут вставлять заголовок фрагментации IPv61.
Как указано в RFC 57222, одна из проблем фрагментации заключается в том, что она создает бреши в системе безопасности. В конце 1990-х годов было совершено несколько известных атак на Windows 95 с использованием перекрывающихся фрагментов IPv43; кроме того, встроенная фрагментация пакетов опасна для того, чтобы попасть в микросхему интернет-маршрутизатора из-за длинного списка проблем, которые необходимо решить. Одна из самых больших проблем заключается в том, что перекрывающиеся фрагменты, буферизованные в маршрутизаторе (ожидающие повторной сборки), потенциально могут привести к уязвимости безопасности на этом устройстве, если с ними неправильно обращаться. Конечным результатом является то, что большинство реализаций маршрутизаторов передают пакеты, требующие фрагментации, программному обеспечению; это не масштабируется на больших скоростях.
Другая проблема заключается в том, что если вы повторно собираете фрагменты, вы должны буферизовать их в течение определенного периода времени, пока не будут получены остальные. Кто-то может использовать эту динамику и отправить очень большое количество незавершенных IP-фрагментов; вынуждая рассматриваемое устройство тратить много ресурсов в ожидании возможности пересборки. Интеллектуальные реализации ограничивают количество ожидающих обработки фрагментов, чтобы предотвратить отказ в обслуживании из-за этого; однако ограничение оставшихся фрагментов может законным образом повлиять на количество допустимых фрагментов, которые могут быть повторно собраны.
Короче говоря, существует слишком много сложных проблем, чтобы маршрутизатор мог справиться с фрагментацией. Если пакеты IPv6 требуют фрагментации, реализации хостов должны быть достаточно умными, чтобы использовать обнаружение MTU пути TCP. Это также подразумевает необходимость сквозного разрешения нескольких сообщений ICMPv6; интересно, что многие администраторы брандмауэров IPv4 блокируют ICMP, чтобы защититься от враждебного сопоставления сети (а затем наивно блокируют все ICMPv6), не понимая, что блокировка всех ICMPv6 незаметно ломает вещи4.
См. раздел 4.5 спецификации Интернет-протокола версии 6 (IPv6).
Из RFC 5722: обработка перекрывающихся фрагментов IPv6:
Обычно используемые брандмауэры используют алгоритм, указанный в [RFC1858], для отсеивания вредоносных пакетов, которые пытаются перезаписать части заголовка транспортного уровня, чтобы обойти проверки входящего соединения. [RFC1858] предотвращает атаку перекрывающихся фрагментов на протокол верхнего уровня (в данном случае TCP), рекомендуя отбрасывать пакеты со смещением фрагмента, равным 1.
Хотя это хорошо работает для фрагментов IPv4, это не сработает для Фрагменты IPv6. Это связано с тем, что фрагментируемая часть пакета IPv6 может содержать заголовки расширения перед заголовком TCP, что делает эту проверку менее эффективной.
См. RFC 4890: рекомендации по фильтрации сообщений ICMPv6 в брандмауэрах.
У меня нет «официального» ответа для вас, но, просто прочитав, как IPv6 обрабатывает слишком большие дейтаграммы, я предполагаю, что нужно уменьшить нагрузку на маршрутизаторы. Фрагментация и повторная сборка несут накладные расходы на маршрутизаторе. IPv6 переносит это бремя на конечные узлы и требует, чтобы они выполнили обнаружение MTU, чтобы определить максимальный размер дейтаграммы, которую они могут отправить. Само собой разумеется, что конечные узлы лучше подходят для этой задачи, поскольку у них меньше данных для обработки. По сути, маршрутизаторов достаточно на своих планшетах; имеет смысл заставить узлы иметь дело с этим и позволить маршрутизаторам просто отбрасывать что-то, что превышает их порог MTU.
В идеале конечным результатом было бы то, что маршрутизаторы могут обрабатывать большую нагрузку в IPv6 (при прочих равных условиях), чем в IPv4, потому что нет никакой фрагментации/повторной сборки, о которой им нужно беспокоиться. Эта мощность процессора может быть выделена для маршрутизации трафика.
Для IPv4 гарантированный минимальный размер MTU составляет 576 байт, для IPv6 — 15001280 байт, а рекомендуемый — 1500 байт. Разница в основном заключается в производительности. Поскольку размер большинства сегментов локальной сети конечного пользователя составляет 1500 байт, это снижает нагрузку на сетевую инфраструктуру для хранения состояния из-за дополнительной фрагментации по сравнению с фактически устаревшими сетями, требующими меньших размеров.
Для UDP в стандартах IPv4 нет определения восстановления фрагментированных пакетов, что означает, что каждая платформа может обрабатывать его по-разному. IPv6 утверждает, что фрагментация и сборка всегда будут происходить в стеке IP, и фрагменты не будут представлены приложениям.
