Пакет IPv6

Пакеты 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]. Байты многобайтовых полей располагаются в сетевом порядке байтов.

Версия (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].

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

Значение 59 («No Next Header») в поле «Следующий заголовок» указывает на отсутствие какого-либо следующего заголовка, включая заголовок верхнеуровневого протокола; с точки зрения заголовка, пакет IPv6 заканчивается немедленно после него: полезная нагрузка должна быть пуста. Однако, если поле «Длина полезной нагрузки» в первом заголовке пакета превышает длину заголовков расширений, в полезной нагрузке всё же могут оставаться данные. Эти данные должны игнорироваться конечными хостами, но передаваться маршрутизаторами без изменения^[1].

Заголовок расширения «Hop-by-Hop Options» может быть обработан и изменён всеми узлами по пути пакета, включая отправителя и получателя. (Для аутентификации опции, меняющиеся в пути, игнорируются.) Заголовок «Destination Options» анализируется только узлом-получателем. Оба заголовка имеют минимальный размер 8 октетов; если опций больше, чем поместится за 8 октетов, блоки по 8 октетов с опциями и заполнением добавляются до полного представления всех опций.

Заголовок расширения «Routing» используется для задания одного или нескольких промежуточных узлов для прохождения пакета перед его доставкой назначению. Минимальный размер заголовка — 8 октетов; если для типа требуется больше данных, чем содержится в 4 октетах, дополнительные блоки по 8 октетов добавляются для размещения всех данных.^[1]

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

Чтобы отправить пакет, превышающий MTU пути, исходящий узел разбивает его на фрагменты. Заголовок расширения «Fragment» содержит всю необходимую для восстановления исходного пакета информацию^[1]

Заголовки Authentication Header и Encapsulating Security Payload входят в состав IPsec и одинаково используются для IPv6 и IPv4.^[18].^[19]

Фиксированный и дополнительные заголовки IPv6 следуют перед «полезной нагрузкой верхнего уровня» — данными транспортного уровня, например, сегментом TCP или датаграммой UDP. Поле «Следующий заголовок» последнего заголовка IPv6 определяет тип данных в этом пакете.

Поле длины полезной нагрузки IPv6, как и у IPv4, имеет размер 16 бит, что позволяет указывать до 65 535 октетов. На практике максимальная пригодная для передачи нагрузка определяется с помощью Path MTU Discovery по минимальному MTU на всём пути передачи пакета. Большинство протоколов канального уровня поддерживают MTU значительно меньше 65 535 октетов.

Опциональная особенность IPv6 — опция «jumbo payload», реализуемая через заголовок расширения Hop-by-Hop^[7], — позволяет передавать пакеты с полезной нагрузкой до одного октета менее 4 ГБ (2³² − 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].