Формат заголовка IPv6: структура, поля и расширенные заголовки

Почему IPv6 изменил заголовок#

Заголовок IPv4 рос органически на протяжении десятилетий. Добавлялись опции, переназначались поля, и в итоге получился заголовок переменной длины с 14 различными полями (некоторые опциональные) и сложной структурой, которую маршрутизаторы должны были тщательно разбирать на каждом хопе.

IPv6 выбрал другой подход: фиксированная длина, упрощенность и оптимизация для быстрой пересылки. Базовый заголовок всегда ровно 40 байт с 8 четко определенными полями. Без опций переменной длины, без контрольной суммы заголовка, без полей фрагментации в основном заголовке.

Результат — заголовок, который маршрутизаторы могут обрабатывать быстрее, который проще реализовать в аппаратуре и который поддерживает расширение без нарушения обратной совместимости. Понимание заголовка IPv6 означает понимание того, почему он построен так, и каких компромиссов достигли разработчики.

40-байтовый базовый заголовок#

Каждый пакет IPv6 начинается ровно с 40 байт в этом формате:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Фиксированный размер. Нет опций в базовом заголовке. Каждый маршрутизатор точно знает, где находится каждое поле, без разбора.

Восемь полей#

Рассмотрим каждое поле в порядке, в котором маршрутизаторы обычно их обрабатывают.

1. Version (4 бита)#

Всегда 6 для пакетов IPv6. Всегда 4 для пакетов IPv4. Это то, как устройства различают IPv6 от IPv4 на проводе.

Практическое значение: Dual-stack системы смотрят на эти 4 бита первыми, чтобы определить, как разбирать остальную часть пакета.

Version = 6 (двоично: 0110)

Просто, неизменно и критически важно для идентификации протокола.

2. Traffic Class (8 бит)#

Ранее называлось «Priority» в ранних спецификациях IPv6, это поле отмечает пакеты для обработки Quality of Service (QoS). Оно служит той же цели, что и Type of Service (ToS) или Differentiated Services Code Point (DSCP) в IPv4.

Структура:

• Биты 0-5: DSCP (Differentiated Services Code Point)
• Биты 6-7: ECN (Explicit Congestion Notification)

Общие значения DSCP:

ECN позволяет маршрутизаторам сигнализировать о перегрузке без сброса пакетов. Он используется современными реализациями TCP для лучшего контроля перегрузки.

Пример:

Traffic Class = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (Не поддерживает ECN)

Маршрутизаторы, поддерживающие QoS, исследуют это поле для приоритизации пакетов. VoIP получает более высокий приоритет, чем загрузка файлов. Видео реального времени получает лучшую обработку, чем электронная почта.

3. Flow Label (20 бит)#

Одна из самых интересных, но недоиспользуемых функций IPv6. Flow Label идентифицирует пакеты, принадлежащие к одному потоку и должные получать идентичную обработку маршрутизации.

Цель:

• Позволить маршрутизаторам идентифицировать связанные пакеты без исследования заголовков верхних уровней
• Поддержка пересылки по быстрому пути для известных потоков
• Предоставление ручки для QoS на основе потока

Спецификация (RFC 6437):

• Значение 0: Пакет не является частью потока
• Значение 1-0xFFFFF: Идентификатор потока (случайно выбирается источником)
• Должно быть согласованным для всех пакетов в потоке
• Должно быть псевдослучайным для хеширования маршрутизатором

Что составляет поток:

• Источник + Назначение + Flow Label уникально идентифицирует его
• Все пакеты в TCP-соединении могут использовать один Flow Label
• Или каждый видеопоток может получить уникальную метку

Практическое использование:

Многие реализации устанавливают Flow Label в 0, потому что:

• Аппаратура, необходимая для хеширования/пересылки на основе Flow Label, не универсальна
• Поддержка приложений ограничена
• Это опционально, и ноль работает нормально

Но при правильном использовании Flow Label позволяет:

• Балансировку нагрузки по ECMP (Equal Cost Multi-Path) маршрутам
• Инженерию трафика на основе потока
• Пересылку аппаратным быстрым путем

Пример установки Flow Label (Linux):

# Включение автоматических flow labels
sysctl -w net.ipv6.auto_flowlabels=1
 
# Flow labels будут устанавливаться на основе хеша 5-кортежа

Linux генерирует flow labels автоматически для TCP-соединений, когда включено, используя хеш адресов источника/назначения и портов.

4. Payload Length (16 бит)#

Длина полезной нагрузки пакета в байтах, исключая 40-байтовый базовый заголовок.

Диапазон: 0 до 65 535 байт

Важные детали:

• Включает расширенные заголовки (если есть) плюс данные верхнего уровня
• НЕ включает базовый 40-байтовый IPv6-заголовок
• Максимальное значение 65 535 означает максимальный размер пакета 65 575 байт (65 535 + 40)

Особый случай: Jumbograms

Для пакетов больше 65 535 байт, Payload Length устанавливается в 0, и расширенный заголовок Hop-by-Hop с опцией Jumbogram несет фактическую длину (до 4 294 967 295 байт).

Jumbograms редки. Они используются на специализированных высокопроизводительных сетях с поддержкой jumbo frames, обычно на каналах 10 Гбит/с+.

Пример:

Payload Length = 1440 байт
  40-байтовый IPv6-заголовок (не считается)
  1440-байтовая полезная нагрузка (TCP-заголовок + данные)
  Всего пакет = 1480 байт

5. Next Header (8 бит)#

Идентифицирует тип заголовка, непосредственно следующего за IPv6-заголовком. Это то, как указываются расширенные заголовки и протоколы верхнего уровня.

Общие значения:

Как работает цепочка:

Каждый расширенный заголовок содержит свое собственное поле Next Header, формируя цепочку:

IPv6 Header (Next Header = 0)
  -> Hop-by-Hop Options (Next Header = 43)
    -> Routing Header (Next Header = 6)
      -> TCP Header
        -> Data

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

Пример без расширенных заголовков:

Next Header = 6 (TCP)
  IPv6-заголовок непосредственно за ним следует TCP-заголовок

Пример с расширенными заголовками:

Next Header = 44 (Fragment)
  IPv6-заголовок за ним следует Fragment header (Next Header = 6)
    Fragment header за ним следует TCP header

6. Hop Limit (8 бит)#

Количество оставшихся хопов маршрутизатора до того, как пакет будет отброшен. Каждый маршрутизатор уменьшает это на 1. Когда достигает 0, маршрутизатор отбрасывает пакет и отправляет ICMPv6-сообщение Time Exceeded.

Диапазон: 0-255

Это эквивалент IPv6 для поля TTL (Time To Live) в IPv4, но название более точное — оно считает хопы, а не время.

Общие начальные значения:

Почему разные значения важны для fingerprinting:

Вы можете угадать исходную ОС, глядя на Hop Limit в полученных пакетах:

Полученный Hop Limit: 56
  56 + 8 хопов = 64 (вероятно Linux/BSD)
 
Полученный Hop Limit: 117
  117 + 11 хопов = 128 (вероятно Windows)

Traceroute использует Hop Limit:

Traceroute работает, отправляя пакеты с увеличивающимися значениями Hop Limit:

• Hop Limit 1: Первый маршрутизатор отвечает Time Exceeded
• Hop Limit 2: Второй маршрутизатор отвечает Time Exceeded
• Hop Limit 3: Третий маршрутизатор отвечает Time Exceeded
• ...пока не достигнуто назначение

Соображения безопасности:

Некоторые атаки используют низкие Hop Limits, чтобы пакеты истекали до достижения систем IDS/IPS. Брандмауэры иногда принудительно устанавливают минимальные значения Hop Limit для входящего трафика.

Пример:

Hop Limit = 64
  Маршрутизатор 1 получает, уменьшает до 63, пересылает
  Маршрутизатор 2 получает, уменьшает до 62, пересылает
  ...
  Маршрутизатор 64 получает, уменьшает до 0, отбрасывает и отправляет ICMPv6 Type 3

7. Source Address (128 бит)#

IPv6-адрес отправителя пакета. Всегда 128 бит, без исключений.

Формат: Стандартная нотация IPv6-адреса

2001:db8:1234:5678:9abc:def0:1234:5678

Особые соображения:

Неопределенный адрес (::) действителен только в конкретных случаях:

• Duplicate Address Detection (DAD)
• DHCP-запросы перед назначением адреса
• Определенные ICMPv6-сообщения

Link-local адреса (fe80::/10) являются действительными адресами источника, но только на локальном канале. Маршрутизаторы не пересылают пакеты с link-local источниками.

Multicast-адреса никогда не являются действительными адресами источника. Пакет с multicast-источником должен быть немедленно отброшен.

Практическая проблема: выбор адреса источника

Когда хост имеет несколько IPv6-адресов (обычно с SLAAC, DHCPv6 и расширениями конфиденциальности), он должен выбрать, какой использовать в качестве источника. RFC 6724 определяет алгоритм выбора, предпочитая:

1. Тот же scope адреса, что и назначение
2. Адреса с более длинным совпадающим префиксом
3. Не устаревшие адреса
4. Адреса с более высоким предпочтением

8. Destination Address (128 бит)#

IPv6-адрес предполагаемого получателя пакета. Как Source Address, всегда 128 бит.

Формат: Стандартная нотация IPv6-адреса

2001:4860:4860::8888

Решение маршрутизации:

Маршрутизаторы исследуют это поле для определения, куда пересылать пакет. В отличие от IPv4, где NAT может переписывать адреса, IPv6-адреса назначения обычно остаются неизменными от конца до конца.

Специальные адреса:

Loopback (::1) никогда не должен появляться в пакете на проводе. Пакеты к ::1 обрабатываются внутренне.

Multicast-адреса (ff00::/8) указывают, что пакет должен быть доставлен нескольким получателям:

• ff02::1 — Все узлы на локальном канале
• ff02::2 — Все маршрутизаторы на локальном канале
• ff02::1:ff00:0/104 — Solicited-node multicast (для Neighbor Discovery)

Модификация заголовка маршрутизации:

Когда присутствует расширенный заголовок Routing, промежуточные узлы могут обрабатывать адрес назначения по-другому, но это редко в современных сетях из-за проблем безопасности.

Сравнение заголовков IPv6 и IPv4#

Понимание того, что изменилось, помогает оценить решения по дизайну.

Что было удалено и почему#

Контрольная сумма заголовка: Маршрутизаторы IPv4 пересчитывают контрольную сумму на каждом хопе, потому что TTL меняется. Это добавляет накладные расходы обработки. IPv6 устраняет её, потому что:

• Канальный уровень (Ethernet) имеет свою контрольную сумму
• Транспортный уровень (TCP/UDP) имеет свою контрольную сумму
• Маршрутизаторам не нужно проверять целостность пакетов — конечные точки это делают

Поле длины заголовка: IPv4 нуждается в этом, потому что опции делают заголовок переменной длины. Фиксированный 40-байтовый заголовок IPv6 делает это поле ненужным.

Поля фрагментации: IPv4 позволяет любому маршрутизатору фрагментировать пакеты. IPv6 требует, чтобы источник выполнял фрагментацию с использованием Path MTU Discovery. Это перемещает сложность на конечные точки и улучшает производительность маршрутизатора.

Опции: Опции IPv4 редко используются, но заставляют маршрутизаторы разбирать заголовки переменной длины. IPv6 перемещает опции в расширенные заголовки, сохраняя базовый заголовок простым.

Расширенные заголовки объяснены#

Расширенные заголовки — это способ IPv6 добавлять функциональность без усложнения базового заголовка. Они появляются между IPv6-заголовком и транспортным уровнем (TCP/UDP), формируя цепочку.

Как работают расширенные заголовки#

Каждый расширенный заголовок содержит поле Next Header, которое указывает на следующий заголовок в цепочке:

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

Хосты обрабатывают расширенные заголовки по порядку. Маршрутизаторы обычно обрабатывают только Hop-by-Hop Options; другие заголовки исследуются только назначением.

Стандартные расширенные заголовки#

RFC 8200 определяет рекомендуемый порядок, когда присутствуют несколько расширенных заголовков:

1. Hop-by-Hop Options (0)
2. Destination Options (для промежуточных назначений при наличии Routing header)
3. Routing (43)
4. Fragment (44)
5. Authentication Header (51)
6. Encapsulating Security Payload (50)
7. Destination Options (60) (для финального назначения)
8. Upper Layer (TCP=6, UDP=17, ICMPv6=58)

Заголовок Hop-by-Hop Options (Type 0)#

Несет опции, которые должны быть исследованы каждым маршрутизатором вдоль пути.

Формат:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Общие опции:

Pad1 и PadN: Заполнение для выравнивания

Router Alert (Type 5): Говорит маршрутизаторам исследовать пакет более внимательно. Используется протоколами вроде MLD (Multicast Listener Discovery).

Jumbogram (Type 194): Для пакетов больше 65 535 байт.

Должен быть первым: Если присутствует, Hop-by-Hop Options должен непосредственно следовать за IPv6-заголовком. RFC 8200 требует этого строгого порядка.

Проблема безопасности: Многие маршрутизаторы отбрасывают пакеты с заголовками Hop-by-Hop, которые они не распознают, или сильно ограничивают их скорость. На практике этот расширенный заголовок редок вне конкретных протоколов (MLD, jumbograms).

Заголовок Routing (Type 43)#

Указывает промежуточные узлы, которые пакет должен посетить перед достижением конечного назначения.

Формат:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     Type-specific data                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Типы маршрутизации:

Type 0 (Устарел): Оригинальная свободная маршрутизация источника. Устарел RFC 5095 из-за проблем безопасности (атаки усиления).

Type 2: Используется Mobile IPv6 для маршрутизации к мобильным узлам. Ограниченный случай использования.

Type 3: Segment Routing Header (SRH) для SRv6. Современный случай использования для инженерии трафика и цепочки сервисов в операторских сетях.

Безопасность: Routing Headers Type 0 позволяли атакующим маршрутизировать пакеты через произвольные узлы, создавая атаки усиления. Большинство сетей отбрасывают Type 0. Type 3 (SRv6) разработан более тщательно, но всё ещё вызывает проблемы безопасности в публичном Интернете.

Заголовок Fragment (Type 44)#

Используется, когда источник фрагментирует пакет, слишком большой для path MTU.

Формат:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля:

• Next Header: Протокол фрагментированных данных (TCP, UDP и т.д.)
• Fragment Offset: Смещение этого фрагмента в исходном пакете (в 8-байтовых единицах)
• M flag: More Fragments (1 = приходит больше, 0 = последний фрагмент)
• Identification: Уникальный ID для повторной сборки (одинаковый для всех фрагментов одного пакета)

Как работает фрагментация:

1. Источник пытается отправить большой пакет
2. Получает ICMPv6-сообщение Packet Too Big
3. Фрагментирует пакет на меньшие части
4. Добавляет Fragment header к каждой части
5. Назначение собирает на основе поля Identification

Пример:

Оригинальный пакет 2000 байт, MTU 1280:

Fragment 1:
  IPv6 Header (40 байт)
  Fragment Header (8 байт) [M=1, Offset=0, ID=12345]
  Data (1232 байта)
  Всего: 1280 байт
 
Fragment 2:
  IPv6 Header (40 байт)
  Fragment Header (8 байт) [M=0, Offset=154, ID=12345]
  Data (768 байт)
  Всего: 816 байт

Минимальный MTU: IPv6 требует, чтобы все каналы поддерживали по крайней мере 1280 байт. Источники могут отправлять 1280-байтовые пакеты без фрагментации в любой совместимой сети IPv6.

Проблемы безопасности: Фрагментация позволяет атаки:

• Перекрывающиеся фрагменты (скрытие полезной нагрузки от IDS)
• Наводнения фрагментами (исчерпание ресурсов повторной сборки)
• Крошечные фрагменты (трата времени обработки)

Многие брандмауэры отбрасывают фрагментированные пакеты или собирают их перед инспекцией.

Заголовок Destination Options (Type 60)#

Несет опции только для узла назначения. Промежуточные маршрутизаторы не обрабатывают его.

Формат: Как Hop-by-Hop Options, но исследуется только в назначении.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Случаи использования:

• Заполнение для выравнивания
• Опции, специфичные для приложения
• Будущие расширения без изменения базового заголовка

Может появляться дважды в цепочке заголовков:

1. До Routing header (обрабатывается промежуточными назначениями)
2. После ESP/AH заголовков (обрабатывается финальным назначением)

Authentication Header (Type 51) и ESP (Type 50)#

IPsec-заголовки, обеспечивающие аутентификацию и шифрование.

AH (51): Предоставляет аутентификацию и целостность, но не конфиденциальность. Редко используется, потому что ESP может делать то же самое плюс шифрование.

ESP (50): Предоставляет конфиденциальность, аутентификацию и целостность. Стандарт для VPN и зашифрованной связи.

IPsec — большая тема за пределами структуры заголовка. Ключевой момент: эти заголовки являются частью дизайна IPv6 с самого начала, в отличие от IPv4, где IPsec был прикреплен позже.

Обработка расширенных заголовков#

Хосты должны:

• Обрабатывать все расширенные заголовки по порядку
• Поддерживать все стандартные расширенные заголовки
• Обрабатывать неизвестные заголовки в соответствии со значением Next Header

Маршрутизаторы обычно:

• Только исследуют Hop-by-Hop Options
• Пересылают другие расширенные заголовки без обработки
• Могут ограничивать скорость или отбрасывать пакеты с определенными заголовками для безопасности

Соображения брандмауэра:

Расширенные заголовки усложняют брандмауэры, потому что:

• Транспортный заголовок (TCP/UDP) может быть глубоко в пакете
• Необходимо разобрать всю цепочку, чтобы найти порты для фильтрации
• Атакующие могут скрывать полезные нагрузки со сложными цепочками заголовков

Лучшие практики:

• Ограничить длину цепочки расширенных заголовков
• Отбрасывать пакеты с устаревшими заголовками (Type 0 Routing)
• Собирать фрагменты перед инспекцией
• Ограничивать скорость пакетов с опциями Hop-by-Hop

Почему нет контрольной суммы?#

IPv4 включает контрольную сумму заголовка, которую маршрутизаторы должны пересчитывать на каждом хопе (потому что TTL меняется). IPv6 намеренно опускает это.

Обоснование:

1. Канальный уровень уже имеет контрольные суммы: Ethernet имеет CRC32. Wi-Fi имеет контрольные суммы. Современные канальные уровни надежны.

2. Контрольные суммы транспортного уровня: TCP и UDP включают контрольные суммы, охватывающие данные и заголовки. Сквозная проверка происходит в любом случае.

3. Производительность маршрутизатора: Пересчет контрольных сумм на каждом хопе тратит циклы CPU. Высокоскоростные маршрутизаторы пересылают миллиарды пакетов в секунду — устранение расчета контрольной суммы помогает.

4. Ошибки редки: Современные сети имеют низкие коэффициенты битовых ошибок. Контрольные суммы улавливают меньше ошибок, чем в 1980-х, когда разрабатывался IPv4.

А как насчет повреждения?

Если бит переворачивается в IPv6-заголовке:

• Неправильный адрес назначения: Пакет идет не туда или отбрасывается, TCP повторно передает
• Неправильный hop limit: Пакет может умереть рано или поздно, маргинальное влияние
• Неправильный next header: Назначение не может разобрать, TCP обнаруживает пропущенные данные и повторно передает

Принцип конец-в-конец гласит, что конечные точки должны обнаруживать и обрабатывать ошибки. Промежуточные маршрутизаторы просто быстро пересылают пакеты.

Практические последствия#

Для сетевых инженеров#

Конфигурация брандмауэра:

• Должен разбирать цепочки расширенных заголовков для поиска транспортных заголовков
• Должен ограничивать глубину цепочки для предотвращения злоупотреблений
• Отбрасывать устаревшие заголовки (Type 0 Routing)

Настройка производительности:

• Отсутствие контрольной суммы заголовка означает более быструю пересылку в аппаратуре
• Фиксированный размер заголовка позволяет лучший pipelining в маршрутизаторах
• Расширенные заголовки могут вызвать обработку по медленному пути

Устранение неполадок:

• tcpdump показывает все заголовки: tcpdump -i eth0 -vv ip6
• Wireshark четко разбирает расширенные заголовки
• Проверьте неожиданные расширенные заголовки, вызывающие сбросы

Для разработчиков#

Программирование сокетов:

• IPv6-сокеты могут получать расширенные заголовки через вспомогательные данные
• Приложениям редко нужно конструировать расширенные заголовки вручную
• ОС обрабатывает фрагментацию автоматически

Конструирование пакетов:

• Устанавливайте Traffic Class для QoS-чувствительных приложений (VoIP, видео)
• Включайте автоматическую генерацию Flow Label для лучшей балансировки нагрузки ECMP
• Не предполагайте, что можете фрагментировать — правильно используйте PMTUD

Безопасность:

• Проверяйте адреса источника (отклоняйте multicast-источники и т.д.)
• Аккуратно обрабатывайте фрагментированные пакеты или отклоняйте их
• Имейте в виду, что middleboxes могут отбрасывать расширенные заголовки

Для системных администраторов#

Конфигурация MTU:

• Убедитесь, что MTU по крайней мере 1280 байт на всех каналах
• Большие MTU улучшают производительность (1500 стандарт, 9000 для jumbo frames)
• Разрешайте ICMPv6 Packet Too Big через брандмауэры

Настройка QoS:

• Настройте маршрутизаторы для учета меток Traffic Class
• Сопоставьте трафик приложений с соответствующими значениями DSCP
• Мониторьте, что политики QoS работают правильно

IPsec/VPN:

• AH и ESP являются расширенными заголовками — брандмауэры должны разрешать их
• IPsec добавляет накладные расходы — учитывайте это в расчетах MTU
• Рассмотрите влияние режима транспорта против режима туннеля на заголовки

Исследование заголовков с помощью инструментов#

tcpdump#

Захват и отображение IPv6-заголовков:

# Базовый захват IPv6-пакетов
sudo tcpdump -i eth0 -n ip6
 
# Подробный вывод, показывающий все поля заголовка
sudo tcpdump -i eth0 -vv ip6
 
# Показать только пакеты с расширенными заголовками
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# Захват фрагментированных пакетов
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

Пример вывода:

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
Анализ:
- Источник: 2001:db8::10, порт 54321
- Назначение: 2001:db8::20, порт 80
- Расширенный заголовок: Destination Options (DSTOPT)
- Транспорт: TCP SYN

Wireshark#

Wireshark предоставляет детальный анализ заголовков:

Фильтры:

# Весь IPv6-трафик
ipv6
 
# Пакеты с конкретными расширенными заголовками
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# Фрагментированные пакеты
ipv6.fragment
 
# Конкретный Traffic Class
ipv6.tclass == 46  # Expedited Forwarding

Инспекция заголовка:

1. Разверните «Internet Protocol Version 6» в деталях пакета
2. Увидьте все 8 полей, четко помеченных
3. Расширенные заголовки появляются как отдельные слои
4. Щелкните правой кнопкой поля для фильтрации

Scapy (Python)#

Создавайте и анализируйте IPv6-пакеты программно:

from scapy.all import *
 
# Создать IPv6-пакет
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# Показать структуру пакета
pkt.show()
 
# Вывод:
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# Добавить расширенный заголовок
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

Распространенные неправильные конфигурации#

Полная блокировка расширенных заголовков#

Проблема: Брандмауэр отбрасывает все пакеты с расширенными заголовками.

Влияние:

• Фрагментация не работает (тип 44 заблокирован)
• IPsec VPN не работают (типы 50/51 заблокированы)
• Некоторый легитимный трафик отбрасывается

Решение: Разрешайте необходимые заголовки (Fragment, AH, ESP), блокируйте устаревшие (Type 0 Routing).

# iptables: Разрешить фрагменты, отбросить Type 0 routing
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Игнорирование Traffic Class#

Проблема: Маршрутизаторы настроены без QoS, все пакеты получают обработку best-effort.

Влияние:

• Страдает качество VoIP
• Буферизация видеопотоков
• Трафик, чувствительный ко времени, конкурирует с массовыми передачами

Решение: Настройте политики QoS на основе Traffic Class/DSCP.

! Пример Cisco IOS
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

Несоответствия MTU#

Проблема: Каналы с MTU < 1280 или брандмауэры, блокирующие ICMPv6 Packet Too Big.

Влияние:

• Соединения зависают
• Большие передачи не работают
• PMTUD не работает

Решение: Убедитесь в минимальном 1280 MTU везде, разрешайте ICMPv6 type 2.

# Установить MTU
ip link set dev eth0 mtu 1500
 
# Проверить
ip -6 link show eth0
 
# Разрешить Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Связанные статьи#

• Основы IPv6 — Понимание базовой адресации IPv6 и концепций перед погружением в заголовки.
• ICMPv6 объяснен — Изучение ICMPv6, который использует значение Next Header 58 и критически важен для IPv6.
• Конфигурация брандмауэра IPv6 — Настройка брандмауэров для правильной обработки IPv6-заголовков и расширенных заголовков.

Часто задаваемые вопросы#