Пакет IPv6
Паке́т IPv6 (англ. IPv6 packet) — это наименьшая единица сообщения, передаваемая с использованием шестой версии протокола Интернета (IPv6).
Пакеты состоят из управляющей информации для адресации и маршрутизации, а также полезной нагрузки, содержащей пользовательские данные. Управляющая информация в пакетах IPv6 делится на обязательный фиксированный заголовок и необязательные заголовки расширений. Полезная нагрузка пакета IPv6 чаще всего представляет собой датаграмму или сегмент протокола более высокого, транспортного уровня, однако может представлять и данные для интернет-уровня — ICMPv6, или канального уровня — OSPF.
Описание
Пакеты IPv6 обычно передаются на канальном уровне по Ethernet или Wi-Fi, который инкапсулирует каждый пакет в кадр. Пакеты также могут быть переданы по протоколу туннелирования вышестоящего уровня, такому как IPv4 при использовании переходных технологий 6to4 или Teredo.
В отличие от IPv4, маршрутизаторы не фрагментируют пакеты IPv6, превышающие максимальную пропускную единицу — MTU; ответственность за это полностью лежит на исходящем узле. IPv6 устанавливает минимальное значение MTU в 1 280 октетов, однако хостам настоятельно рекомендуется использовать Path MTU Discovery для использования максимальных размеров пакетов возможных на маршруте[1].
С июля 2017 года Управление присвоением интернет-номеров — IANA, отвечает за регистрацию всех параметров IPv6, используемых в заголовках пакетов IPv6[1].
Фиксированный заголовок
Фиксированный заголовок начинает пакет IPv6 и имеет размер 40 октетов (320 битов)[1]. Байты многобайтовых полей располагаются в сетевом порядке байтов.
| Смещение (октеты) | Поле (бит) | ||
|---|---|---|---|
| 0 | Версия (4) | Класс трафика (8) | Метка потока (20) |
| 4 | Длина полезной нагрузки (16) | Следующий заголовок (8) | Лимит переходов (8) |
| 8 | Адрес источника (128) | ||
| 24 | Адрес назначения (128) |
- Версия (4 бита)
- Постоянное значение 6 (битовая последовательность 0110).
- Класс трафика (6+2 бита)
- Этот набор битов содержит два значения. Шесть старших бит содержат поле дифференцированных сервисов — DS, используемое для классификации пакетов[2][3]. Все стандартные DS-поля сейчас оканчиваются битом '0'. Любое поле DS, заканчивающееся двумя '1', предназначено для локального или экспериментального использования[4]. Два младших бита — для Explicit Congestion Notification (ECN). Приоритеты трафика делятся на диапазоны: трафик с контролем перегрузки от источника и трафик без контроля перегрузки.
- Метка потока (20 бит)
- Идентификатор с высокой энтропией для потока пакетов между источником и получателем. Например, поток TCP или медиапоток. Метка потока «0» означает, что пакет не принадлежит ни одному потоку. В старой схеме поток идентифицируется по адресам и портам источника и получателя и протоколу — значение последнего поля «Следующий заголовок»[5]. Также предлагалось использовать метку потока для обнаружения поддельных пакетов[6].
- Длина полезной нагрузки (16 бит)
- Размер полезной нагрузки в октетах, включая любые заголовки расширений. Значение устанавливается в ноль, если расширение Hop-by-Hop содержит опцию Jumbo Payload[7].
- Следующий заголовок (8 бит)
- Определяет тип следующего заголовка. Обычно указывает на транспортный протокол полезной нагрузки, либо указывает на следующий заголовок расширения. Значения разделены с аналогичным полем в IPv4.
- Лимит переходов (8 бит)
- Заменяет поле TTL в IPv4. Значение декрементируется на каждом промежуточном узле, и пакет удаляется при достижении нуля. Однако получающий узел должен обработать пакет даже с лимитом переходов, равным нулю.
- Адрес источника (128 бит)
- Уникаст-адрес IPv6 отправляющего узла.
- Адрес назначения (128 бит)
- Unicast- или мультикаст-адрес IPv6 получающего узла.
Для повышения производительности и с учётом того, что современные технологии канального уровня и транспортные протоколы обеспечивают достаточное обнаружение ошибок[8], заголовок не включает контрольную сумму[1].
Заголовки расширений
Заголовки расширений содержат дополнительную опциональную информацию интернет-уровня и располагаются между фиксированным заголовком и заголовком протокола вышестоящего уровня[1]. Заголовки расширений формируют цепочку, используя поле «Следующий заголовок». Поле «Следующий заголовок» фиксированного заголовка указывает тип первого заголовка расширения; в последнем заголовке расширения это поле определяет тип заголовка или протокола полезной нагрузки. Все заголовки расширений имеют размер, кратный 8 октетам; для этого некоторые из них требуют внутреннего дополнения нулями.
Существуют различные типы заголовков расширений, и новые типы могут появляться в будущем. Большинство заголовков расширений анализируется и обрабатывается только на узле-получателе. Расширение «Hop-by-Hop Options» может быть обработано и изменено промежуточными узлами и, если используется, всегда должно быть первым заголовком расширения. Все заголовки расширений опциональны и не должны повторяться более одного раза, за исключением «Destination Options», который может встречаться дважды[1].
Если узел не распознаёт конкретный заголовок расширения, он должен отбросить пакет и отправить сообщение «Parameter Problem» — ICMPv6, тип 4, код 1[1].
Ниже перечислены определённые заголовки расширений в рекомендуемом порядке для случая, если после фиксированного заголовка присутствует более одного заголовка расширения.
| Заголовок расширения | Значение поля «Следующий заголовок» | Описание |
|---|---|---|
| Hop-by-Hop Options | 0 | Опции, которые должны анализироваться всеми устройствами на пути |
| Routing | 43 | Методы указания маршрута для датаграммы (например, для Mobile IPv6) |
| Fragment | 44 | Содержит параметры для фрагментации пакетов |
| Authentication Header (AH) | 51 | Сведения, используемые для проверки аутентичности частей пакета |
| Encapsulating Security Payload (ESP) | 50 | Несёт зашифрованные данные для защищённого обмена |
| Destination Options (перед заголовком верхнего уровня) | 60 | Опции, которые должны анализироваться только получателем пакета |
| Mobility | 135 | Параметры, используемые с Mobile IPv6 |
| Host Identity Protocol | 139 | Используется для HIPv2[9] |
| Shim6 Protocol | 140 | Используется для Shim6[10] |
| Зарезервировано | 253 | Для экспериментов и тестирования[4][11] |
| Зарезервировано | 254 | Для экспериментов и тестирования[4][11] |
Значение 59 («No Next Header») в поле «Следующий заголовок» указывает на отсутствие какого-либо следующего заголовка, включая заголовок верхнеуровневого протокола; с точки зрения заголовка, пакет IPv6 заканчивается немедленно после него: полезная нагрузка должна быть пуста. Однако, если поле «Длина полезной нагрузки» в первом заголовке пакета превышает длину заголовков расширений, в полезной нагрузке всё же могут оставаться данные. Эти данные должны игнорироваться конечными хостами, но передаваться маршрутизаторами без изменения[1].
Hop-by-hop options и destination options
Заголовок расширения «Hop-by-Hop Options» может быть обработан и изменён всеми узлами по пути пакета, включая отправителя и получателя. (Для аутентификации опции, меняющиеся в пути, игнорируются.) Заголовок «Destination Options» анализируется только узлом-получателем. Оба заголовка имеют минимальный размер 8 октетов; если опций больше, чем поместится за 8 октетов, блоки по 8 октетов с опциями и заполнением добавляются до полного представления всех опций.
| Поле | Длина | Описание |
|---|---|---|
| Следующий заголовок | 8 бит | Указывает тип следующего заголовка |
| Длина расширения | 8 бит | Длина этого заголовка в единицах по 8 октетов, не считая первых 8 октетов. |
| Опции и заполнение | переменная | Одна или более опций, а также необходимые для выравнивания поля заполнения. Опции кодируются по схеме TLV. |
Маршрутизация
Заголовок расширения «Routing» используется для задания одного или нескольких промежуточных узлов для прохождения пакета перед его доставкой назначению. Минимальный размер заголовка — 8 октетов; если для типа требуется больше данных, чем содержится в 4 октетах, дополнительные блоки по 8 октетов добавляются для размещения всех данных[1].
| Поле | Длина | Описание |
|---|---|---|
| Следующий заголовок | 8 бит | Тип следующего заголовка |
| Длина расширения | 8 бит | Величина заголовка в 8-октетных блоках, не считая первых 8 байт |
| Тип маршрутизации | 8 бит | Значение 0-255, присваивается IANA[12] |
| Сегментов осталось | 8 бит | Сколько узлов пакету ещё предстоит пройти до финального назначения |
| Специфические для типа данные | переменная | Зависит от типа маршрутизации |
Типы маршрутизации:
| Тип | Статус | Комментарий |
|---|---|---|
| 0 | Устаревший | Позволял простую, но опасную атаку отказа в обслуживании; устарел в 2007 и должен быть игнорирован[13][14] |
| 1 | Устаревший | Использовался проектом Nimrod[15], устарел в 2009 году |
| 2 | Разрешён | Ограниченная версия типа 0, используется для Mobile IPv6 |
| 3 | Разрешён | RPL Source Route Header[16] для сетей с низким энергопотреблением и потерями |
| 4 | Разрешён | Segment Routing Header (SRH)[17] |
| 253 | Частное использование | Для тестов, не для реальных внедрений (RFC3692-style Experiment 1) |
| 254 | Частное использование | Для тестов, не для реальных внедрений (RFC3692-style Experiment 2) |
Фрагментация
Чтобы отправить пакет, превышающий MTU пути, исходящий узел разбивает его на фрагменты. Заголовок расширения «Fragment» содержит всю необходимую для восстановления исходного пакета информацию[1].
| Поле | Длина | Описание |
|---|---|---|
| Следующий заголовок | 8 бит | Тип следующего заголовка |
| Зарезервировано | 8 бит | Ноль (зарезервировано) |
| Смещение фрагмента | 13 бит | Смещение в единицах по 8 октетов |
| Зарезервировано 2 | 2 бита | Зарезервировано, должны быть нули |
| Флаг M | 1 бит | 1 — есть ещё фрагменты; 0 — последний фрагмент |
| Идентификатор | 32 бита | Значение для идентификации пакета, генерируемое отправителем для восстановления |
Полезная нагрузка
Фиксированный и дополнительные заголовки IPv6 следуют перед «полезной нагрузкой верхнего уровня» — данными транспортного уровня, например, сегментом TCP или датаграммой UDP. Поле «Следующий заголовок» последнего заголовка IPv6 определяет тип данных в этом пакете.
Стандартная длина полезной нагрузки
Поле длины полезной нагрузки IPv6, как и у IPv4, имеет размер 16 бит, что позволяет указывать до 65 535 октетов. На практике максимальная пригодная для передачи нагрузка определяется с помощью Path MTU Discovery по минимальному MTU на всём пути передачи пакета. Большинство протоколов канального уровня поддерживают MTU значительно меньше 65 535 октетов.
Джамбограммы
Опциональная особенность IPv6 — опция «jumbo payload», реализуемая через заголовок расширения Hop-by-Hop[7], — позволяет передавать пакеты с полезной нагрузкой до одного октета менее 4 ГБ (232 − 1 = 4 294 967 295 октетов), используя 32-битное поле длины. Такие пакеты называются джамбограммами.
Поскольку и TCP, и UDP используют 16-битные поля — длина, указатель экстренных данных, поддержка джамбограмм IPv6 требует модификаций реализации транспортного уровня[7]. Джамбограммы актуальны только для каналов, где возможен MTU более 65 583 октетов — длина полезной нагрузки превышает 65535, плюс 40 байт фиксированного заголовка и 8 байт расширения Hop-by-Hop. Лишь немногие протоколы канального уровня способны обработать пакеты такого размера.
Фрагментация
В отличие от IPv4, маршрутизаторы IPv6 никогда не фрагментируют пакеты. Пакеты, превышающие MTU звена назначения, отбрасываются, и исходному узлу возвращается сообщение «Packet too big» (ICMPv6), аналогично методу IPv4 при выставленном флаге «Don’t Fragment»[1]. Конечные узлы должны использовать Path MTU Discovery для определения максимального размера пакета, а использование заголовка расширения «Fragment» допустимо только при невозможности такого ограничения на верхнем уровне.
Любой канал передачи, по которому передаются данные IPv6, обязан поддерживать передачу пакета размером минимум 1 280 байт; поэтому, чтобы избежать фрагментации и необходимости Path MTU Discovery, отправитель может ограничить пакеты этим размером.
Фрагментирование
Пакет, содержащий первый фрагмент исходного (большого) пакета, состоит из: заголовков для каждого фрагмента — важные исходные заголовки, повторяющиеся для каждого фрагмента, заголовка расширения Fragment с нулевым смещением, всех остальных оригинальных расширений, исходного заголовка верхнего уровня и части полезной нагрузки[1]. Каждый следующий пакет состоит из собственных заголовков, Fragment-заголовка и очередной порции исходной полезной нагрузки, определяемой смещением фрагмента.
Набор заголовков для каждого фрагмента определяется наличием «Routing» либо «Hop-by-Hop» расширения: если их нет, только фиксированный заголовок. Если есть «Routing», то все заголовки до и включая его; если есть «Hop-by-Hop Options» — фиксированный заголовок и данный заголовок.
В любом случае последний заголовок из этой серии имеет значение поля «Следующий заголовок» 44, что указывает на следующий Fragment-заголовок. Во всех Fragment-заголовках, кроме последнего, флаг M выставляется в 1 — фрагменты есть ещё, в последнем — в 0. Длина каждого фрагмента — кратна 8 октетам, кроме, возможно, последнего.
Так называемые раньше «нефрагментируемые части» исторически означали возможность фрагментации остальных заголовков; однако с 2014 года никакие заголовки больше не фрагментируются[20].
Сборка фрагментов
Оригинальный пакет собирается получающим узлом по всем поступившим фрагментам, размещая их по указанным смещениям и отбрасывая заголовки Fragment. Фрагменты могут приходить в любом порядке и будут упорядочены узлом получателя.
Если не все фрагменты поступили в течение 60 секунд после первого фрагмента, сборка пакета отменяется и все хранящиеся фрагменты отбрасываются. Если первый фрагмент (с фиксированным заголовком) получен, но других не хватает, отправляется сообщение «Time Exceeded» — ICMPv6, тип 3, код 1, источнику.
Если при восстановлении обнаруживается, что один фрагмент перекрывает другой, сборка пакета прекращается и все фрагменты удаляются. Узел может игнорировать точные дубликаты фрагментов вместо того, чтобы считать их перекрывающими[1].
Получающие хосты должны пытаться собирать фрагментированные IP-датаграммы размером до 1 500 байт после сборки. Разрешается собирать и большие датаграммы, но также разрешается их молча удалять, если пакет после сборки превышает 1 500 байт. Поэтому отправителям не рекомендуется фрагментировать пакеты так, чтобы общий размер после сборки превышал 1 500 байт, если только они не уверены, что принимающий способен обработать такие пакеты.
Безопасность
Исследования показали, что фрагментация может быть использована для обхода средств сетевой безопасности. В 2014 году поэтому была запрещена практика размещения избыточно длинных цепочек заголовков IPv6 за пределами первого фрагмента. Кроме того, по результатам исследований методов обхода защиты Router Advertisement Guard,[21]. фрагментация для Neighbor Discovery устарела, а для Secure Neighbor Discovery её использование считается нежелательным[22].