Каковы современные политики ОС в отношении фрагментации IPv6?

Question

Хотелось бы знать - если написать простой анализатор пакетов, способный работать с IPv6, который будет анализировать трафик, собранный между машинами Windows ( Vista или выше) и RHEL5 - каковы шансы увидеть там фрагментированные пакеты IPv6 , то есть что эти ОС будут выполнять фрагментацию пакетов IPv6?

Я знаю, что технически это может быть там и описано в RFC, но принимая во внимание риски безопасности, связанные с фрагментацией, известные в эпоху IPv4, - мне интересно - почему современные сетевые стеки не отбрасывают функциональность фрагментации IP6 привсе?Зачем нам это все еще, туннелирование или что-то еще?

Обновление : как я уже упоминал выше, фрагментация IP создает риски для безопасности.Вот ссылки для поддержки этого утверждения:

• Атаки фрагментации IP
• Вопросы безопасности для фильтрации фрагментов IP
• Обработка перекрывающихся фрагментов IPv6

Answer 1

отредактировано от оригинала: Итак, маршрутизаторы IPv6 не могут фрагментировать пакеты, они отбрасываются и возвращается слишком большой пакет ICMPv6. Это означает, что конечные узлы выполняют согласование на MTU канала. Однако это все описывает канальный уровень, в соответствии с OSI, верхние уровни не должны заботиться обо всех деталях нижних уровней.

Предполагается, что в оборудовании IPv4 может поддерживаться гумограммы размером до 9 000 байт, но размер дейтаграмм может достигать 64 КБ. С TCP ОС может использовать базовый размер канала и оптимально разделять поток данных, все хорошо. Однако в UDP поддержка обработки таких согласований ограничена выше, чем системный администратор, замечающий проблемы и переконфигурирующий программное обеспечение.

Допустим, у вас есть какое-то программное обеспечение с фиксированным размером дейтаграммы 8000 байт, для перехода с IPv4 на IPv6 есть выбор фрагментации, если сквозной MTU составляет, скажем, всего 1500 байт, или отбрасывание всего. В хорошей очистке вы просите полностью отбросить фрагментацию, но это сломает приложение, требующее переписать больше, чем просто обработка инициализации сокета.

IPv6 по-прежнему является IP, идея состоит не в том, чтобы ломать все, представленные изменения отбрасывают все функции, которые влияют на производительность: рекомендуется минимум 1500 (например, 576 в IPv4, ср. 68/1280 абс. Мин), а не фрагментация в пути.

Страница Cisco с подробным описанием различных ограничений MTU из-за аппаратного обеспечения ASIC:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml

Примеры

В Linux 2.6.38-10-generic с IPv4 и IPv6 . IPv4 показывает фрагментацию в Wireshark, IPv6 показывает только фрагментацию прикладного уровня.

tcpdump показывает это:

11:13: IP aiko.hk.miru.hk.37505 > 239.192.0.1.7600: UDP, length 1972
11:13: IP aiko.hk.miru.hk.37505 > 239.192.0.1.7600: UDP, length 1117
11:15: IP6 fe80::230:1bff:feb7:a209.51993 > ff08::1.7600: UDP, length 1137

Пакеты имеют PGM выше UDP, а не IPv4 или IPv6. Полезная нагрузка 3000 байтов с MTU 2000 байтов, поэтому должна быть фрагментация IP и фрагментация PGM.

Answer 2

Если какое-либо приложение попытается создать дейтаграмму UDP с использованием IPv6 через стандартное соединение Ethernet (отключенные большие кадры) с общей полезной нагрузкой (включая заголовки), превышающей 1500 байтов, то вы гарантированно увидите фрагментацию на IPv6layer.

Стек может решить начать вставку фрагментов раньше, начиная с общей полезной нагрузки (включая заголовки) всего 1280 байтов, в зависимости от результатов анализа MTU пути.

Answer 3

В Linux пакеты IPv6 будут отправляться фрагментированно, если верхний уровень предоставляет пакет, размер которого превышает MTU обнаруженного канала, для TCP это не произойдет.

Answer 4

Делая это с IPv6, вы нарушите:

ICMP, UDP, TCP-перенаправители, реализации TCP, которые повторно передают ранее отправленный кадр фрагментами из-за получения слишком большого пакета и любого другого протокола уровня IP, ожидающегобыть в состоянии передать сообщение размером> MTU, в котором отсутствует уровень фрагментации конкретного протокола.

UDP особенно огромен.Существуют развернутые системы, которые зависят от этой работы, для которых нет альтернативного решения.Вы можете сломать некоторые SIP или SNMP, но по большей части их можно настроить и обойти с помощью ручек.Другие протоколы, такие как RADIUS, не предлагают таких опций и просто прекратят работу без помощи.