Пакет IPv6 — это наименьший элемент сообщения, которым обмениваются с использованием протокола Интернета версии 6 (IPv6). Пакеты состоят из управляющей информации для адресации и маршрутизации, а также полезной нагрузки пользовательских данных. Управляющая информация в пакетах IPv6 подразделяется на обязательный фиксированный заголовок и необязательные заголовки расширения. Полезная нагрузка пакета IPv6 обычно представляет собой датаграмму или сегмент протокола транспортного уровня более высокого уровня , но может быть данными для интернет-уровня (например, ICMPv6 ) или канального уровня (например, OSPF ).
Пакеты IPv6 обычно передаются по канальному уровню (т. е. по Ethernet или Wi-Fi ), который инкапсулирует каждый пакет в кадр . Пакеты также могут передаваться по туннельному протоколу более высокого уровня , такому как IPv4 при использовании технологий перехода 6to4 или Teredo .
В отличие от IPv4, маршрутизаторы не фрагментируют пакеты IPv6, превышающие максимальный размер передаваемого блока (MTU), это является исключительной ответственностью исходного узла. Минимальный размер MTU в 1280 октетов предписан IPv6, но хостам «настоятельно рекомендуется» использовать Path MTU Discovery, чтобы воспользоваться преимуществами MTU, превышающими минимальный. [1]
С июля 2017 года Управление по распределению адресов в Интернете (IANA) отвечает за регистрацию всех параметров IPv6, которые используются в заголовках пакетов IPv6. [1]
Фиксированный заголовок начинает пакет IPv6 и имеет размер 40 октетов (320 бит ). [1] Байты многобайтовых полей располагаются в сетевом порядке байтов .
Для повышения производительности, а также поскольку предполагается, что современные технологии канального уровня и протоколы транспортного уровня обеспечивают достаточное обнаружение ошибок [9] , заголовок не имеет контрольной суммы для его защиты. [1]
Заголовки расширений несут необязательную информацию уровня Интернета и размещаются между фиксированным заголовком и заголовком протокола верхнего уровня. [1] Заголовки расширений образуют цепочку, используя поля Next Header . Поле Next Header в фиксированном заголовке указывает тип первого заголовка расширения; поле Next Header последнего заголовка расширения указывает тип заголовка протокола верхнего уровня в полезной нагрузке пакета. Все заголовки расширений имеют размер, кратный 8 октетам; некоторые заголовки расширений требуют внутреннего заполнения для выполнения этого требования.
Определено несколько заголовков расширений, и в будущем могут быть определены новые заголовки расширений. Большинство заголовков расширений проверяются и обрабатываются в месте назначения пакета. Параметры Hop-by-Hop могут обрабатываться и изменяться промежуточными узлами и, если они присутствуют, должны быть первым расширением. Все заголовки расширений являются необязательными и должны появляться не более одного раза, за исключением расширения заголовка Destination Options , которое может появляться дважды. [1]
Если узел не распознает определенный заголовок расширения, он должен отбросить пакет и отправить сообщение о проблеме с параметрами ( ICMPv6 тип 4, код 1). [1]
Определенные ниже заголовки расширений перечислены в предпочтительном порядке для случая, когда за фиксированным заголовком следует более одного заголовка расширений.
Значение 59 (No Next Header) в поле Next Header указывает на то, что за этим заголовком вообще нет следующего заголовка , даже заголовка протокола верхнего уровня. Это означает, что с точки зрения заголовка пакет IPv6 заканчивается сразу после него: полезная нагрузка должна быть пустой. Однако в полезной нагрузке все еще могут быть данные, если длина полезной нагрузки в первом заголовке пакета больше длины всех заголовков расширения в пакете. Эти данные должны игнорироваться хостами, но передаваться маршрутизаторами без изменений. [1] : 4.7
Заголовок расширения Hop-by-Hop Options может быть проверен и изменен всеми узлами на пути пакета, включая отправляющие и принимающие узлы. (Для аутентификации значения опций, которые могут меняться по пути, игнорируются.) Заголовок расширения Destination Options должен быть проверен только узлом(ами) назначения. Оба заголовка расширения имеют размер не менее 8 октетов; если присутствует больше опций, чем помещается в этом пространстве, блоки из 8 октетов, содержащие опции и заполнение, добавляются к заголовку повторно, пока все опции не будут представлены.
Заголовок расширения маршрутизации используется для направления пакета на один или несколько промежуточных узлов перед отправкой в пункт назначения. Заголовок имеет размер не менее 8 октетов; если требуется больше данных, специфичных для типа , чем помещается в 4 октета, блоки по 8 октетов добавляются к заголовку повторно, пока все данные, специфичные для типа, не будут размещены. [1]
Чтобы отправить пакет, который больше, чем MTU пути , отправляющий узел разбивает пакет на фрагменты. Заголовок расширения Fragment несет информацию, необходимую для повторной сборки исходного (нефрагментированного) пакета. [1]
Заголовок аутентификации и инкапсулирующая полезная нагрузка безопасности являются частью IPsec и используются одинаково в IPv6 и IPv4. [19] [20]
За фиксированными и необязательными заголовками IPv6 следует полезная нагрузка верхнего уровня , данные, предоставляемые транспортным уровнем, например, сегмент TCP или датаграмма UDP . Поле Next Header последнего заголовка IPv6 указывает, какой тип полезной нагрузки содержится в этом пакете.
Поле длины полезной нагрузки IPv6 (и IPv4 ) имеет размер 16 бит, что позволяет указать максимальную длину65 535 октетов для полезной нагрузки. На практике хосты определяют максимальную полезную длину полезной нагрузки с помощью Path MTU Discovery (выдавая минимальный MTU по пути от отправителя к получателю), чтобы избежать необходимости фрагментировать пакеты. Большинство протоколов канального уровня имеют MTU значительно меньше, чем65 535 октетов.
Дополнительная функция IPv6, опция jumbo payload в заголовке расширения Hop-By-Hop Options [8], позволяет обмениваться пакетами с полезной нагрузкой до одного октета менее 4 ГБ (2 32 − 1 = 4 294 967 295 октетов), используя 32-битное поле длины. Пакеты с такой полезной нагрузкой называются джамбограммами .
Поскольку и TCP , и UDP включают поля, ограниченные 16 битами (длина, указатель срочных данных), поддержка джамбограмм IPv6 требует внесения изменений в реализацию протокола транспортного уровня. [8] Джамбограммы актуальны только для соединений, имеющих MTU больше, чем65 583 октета (более65 535 октетов для полезной нагрузки, плюс 40 октетов для фиксированного заголовка, плюс 8 октетов для заголовка расширения Hop-by-Hop ). Только несколько протоколов канального уровня могут обрабатывать пакеты размером более65 535 октетов. [ необходима ссылка ]
В отличие от IPv4, маршрутизаторы IPv6 никогда не фрагментируют пакеты IPv6. Пакеты, превышающие размер максимального блока передачи (MTU) целевого канала, отбрасываются, и это состояние сигнализируется сообщением ICMPv6 Packet too big исходному узлу, аналогично методу IPv4, когда установлен бит Don't Fragment . [1] Ожидается, что конечные узлы в IPv6 выполнят Path MTU Discovery для определения максимального размера отправляемых пакетов, а протокол верхнего уровня должен ограничить размер полезной нагрузки. Если протокол верхнего уровня не может этого сделать, отправляющий хост может вместо этого использовать заголовок расширения Fragment.
Любой канальный уровень, передающий данные IPv6, должен быть способен передавать IP-пакет, содержащий до 1280 байт, поэтому отправляющая конечная точка может ограничить свои пакеты 1280 байтами и избежать необходимости фрагментации или обнаружения MTU пути.
Пакет, содержащий первый фрагмент исходного (более крупного) пакета, состоит из пяти частей: заголовков каждого фрагмента (важнейшие исходные заголовки, которые многократно используются в каждом фрагменте), за которыми следует заголовок расширения фрагмента , содержащий нулевое смещение, затем все оставшиеся исходные заголовки расширения, затем исходный заголовок верхнего уровня (альтернативно заголовок ESP) и часть исходной полезной нагрузки. [1] Каждый последующий пакет состоит из трех частей: заголовков каждого фрагмента, за которыми следует заголовок расширения фрагмента и часть исходной полезной нагрузки, идентифицированная смещением фрагмента.
Заголовки по фрагментам определяются на основе того, содержит ли оригинал заголовок расширения Routing или Hop-by-Hop . Если ни один из них не существует, то фрагментная часть представляет собой только фиксированный заголовок. Если существует заголовок расширения Routing , то фрагментные заголовки включают фиксированный заголовок и все заголовки расширения вплоть до заголовка Routing включительно . Если существует заголовок расширения Hop-by-Hop , то фрагментные заголовки состоят только из фиксированного заголовка и заголовка расширения Hop-by-Hop .
В любом случае, последний заголовок части per-fragment имеет значение Next Header, установленное на 44, чтобы указать, что следует заголовок расширения Fragment . Каждый заголовок расширения Fragment имеет свой флаг M , установленный на 1 (указывающий на то, что следуют еще фрагменты), за исключением последнего, флаг которого установлен на 0. Длина каждого фрагмента кратна 8 октетам, за исключением, возможно, последнего фрагмента.
Заголовки по фрагментам исторически назывались «нефрагментируемой частью», имея в виду возможность фрагментации остальной части заголовка до 2014 года. Теперь ни один заголовок не является фактически фрагментируемым. [21]
Исходный пакет собирается принимающим узлом повторно путем сбора всех фрагментов и размещения каждого фрагмента по указанному смещению и отбрасывания заголовков расширения фрагмента пакетов, которые их несли. Пакеты, содержащие фрагменты, не обязательно должны прибывать последовательно; они будут переупорядочены принимающим узлом.
Если не все фрагменты получены в течение 60 секунд после получения первого пакета с фрагментом, повторная сборка исходного пакета прекращается, и все фрагменты отбрасываются. Если был получен первый фрагмент (содержащий фиксированный заголовок), а один или несколько других отсутствуют, то узлу, отправившему фрагментированный пакет, возвращается сообщение Time Exceeded ( ICMPv6 тип 3, код 1).
Когда узел повторной сборки обнаруживает фрагмент, который перекрывается с другим фрагментом, повторная сборка исходного пакета прерывается, и все фрагменты отбрасываются. Узел может опционально игнорировать точные дубликаты фрагмента вместо того, чтобы рассматривать точные дубликаты как перекрывающие друг друга. [1]
Принимающие хосты должны сделать все возможное, чтобы собрать фрагментированные IP-дейтаграммы, которые после сборки содержат до 1500 байт. Хостам разрешено пытаться собрать фрагментированные IP-дейтаграммы размером более 1500 байт, но им также разрешено молча отбрасывать любые датаграммы после того, как станет очевидно, что собранный заново пакет будет больше 1500 байт. Поэтому отправители должны избегать отправки фрагментированных IP-дейтаграмм с общим размером после сборки более 1500 байт, если только они не знают, что получатель способен собрать такие большие датаграммы.
Исследования показали, что использование фрагментации может быть использовано для обхода контроля сетевой безопасности. В результате в 2014 году ранее допускаемое переполнение цепочки заголовков IPv6 за пределы первого фрагмента было запрещено, чтобы избежать некоторых очень патологических случаев фрагментации. [21] Кроме того, в результате исследования обхода Router Advertisement Guard, [22] использование фрагментации с Neighbor Discovery устарело, а использование фрагментации с Secure Neighbor Discovery (SEND) не рекомендуется. [23]
Тип 0: злой механизм...