Пакет 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] Заголовки расширений образуют цепочку, используя поля «Следующий заголовок» . Поле «Следующий заголовок» в фиксированном заголовке указывает тип первого заголовка расширения; Поле « Следующий заголовок» последнего заголовка расширения указывает тип заголовка протокола верхнего уровня в полезной нагрузке пакета. Все заголовки расширений имеют размер, кратный 8 октетам; некоторые заголовки расширений требуют внутреннего заполнения для удовлетворения этого требования.
Определено несколько заголовков расширений, и в будущем могут быть определены новые заголовки расширений. Большинство заголовков расширений проверяются и обрабатываются в пункте назначения пакета. Пошаговые параметры могут обрабатываться и модифицироваться промежуточными узлами и, если они присутствуют, должны быть первым расширением. Все заголовки расширений являются необязательными и должны появляться не более одного раза, за исключением расширения заголовка «Параметры места назначения» , которое может появляться дважды. [1]
Если узел не распознает конкретный заголовок расширения, он должен отбросить пакет и отправить сообщение о проблеме с параметром ( ICMPv6 тип 4, код 1). [1]
Определенные заголовки расширений ниже перечислены в предпочтительном порядке для случая, когда за фиксированным заголовком следует более одного заголовка расширения.
Значение 59 (Нет следующего заголовка) в поле «Следующий заголовок» указывает на то, что после этого заголовка нет никакого следующего заголовка , даже заголовка протокола верхнего уровня. Это означает, что с точки зрения заголовка пакет 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, опция большой полезной нагрузки в заголовке расширения 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 октетов для заголовка пошагового расширения ). Лишь немногие протоколы канального уровня могут обрабатывать пакеты размером более65 535 октетов. [ нужна цитата ]
В отличие от IPv4, маршрутизаторы IPv6 никогда не фрагментируют пакеты IPv6. Пакеты, превышающие размер максимальной единицы передачи (MTU) канала назначения, отбрасываются, и об этом условии сигнализирует сообщение ICMPv6 « Пакет слишком большой» исходному узлу, аналогично методу IPv4, когда установлен бит «Не фрагментировать» . [1] Ожидается, что конечные узлы в IPv6 будут выполнять обнаружение Path MTU для определения максимального размера отправляемых пакетов, а протокол верхнего уровня, как ожидается, будет ограничивать размер полезной нагрузки. Если протокол верхнего уровня не может этого сделать, хост-отправитель может вместо этого использовать заголовок расширения фрагмента.
Любой уровень канала передачи данных, передающий данные IPv6, должен быть способен передавать IP-пакет, содержащий до 1280 байтов, таким образом, отправляющая конечная точка может ограничить свои пакеты до 1280 байтов и избежать необходимости во фрагментации или обнаружении MTU пути.
Пакет, содержащий первый фрагмент исходного (большого) пакета, состоит из пяти частей: заголовков для каждого фрагмента (важнейшие исходные заголовки, которые неоднократно используются в каждом фрагменте), за которыми следует заголовок расширения фрагмента , содержащий нулевое смещение, а затем все оставшиеся исходные заголовки расширения, затем исходный заголовок верхнего уровня (альтернативно заголовок ESP) и часть исходной полезной нагрузки. [1] Каждый последующий пакет состоит из трех частей: заголовков для каждого фрагмента, за которыми следует заголовок расширения фрагмента , а также часть исходной полезной нагрузки, определяемая смещением фрагмента.
Заголовки для каждого фрагмента определяются на основе того, содержит ли оригинал заголовок расширения маршрутизации или шаг-за-шагом . Если ни один из них не существует, фрагментная часть представляет собой просто фиксированный заголовок. Если заголовок расширения маршрутизации существует, заголовки для каждого фрагмента включают фиксированный заголовок и все заголовки расширения, включая заголовок маршрутизации . Если заголовок расширения Hop-by-Hop существует, заголовки каждого фрагмента состоят только из фиксированного заголовка и заголовка расширения Hop-by-Hop .
В любом случае для последнего заголовка фрагментной части значение Next Header установлено равным 44, что указывает на то, что за ним следует заголовок расширения фрагмента . Каждый заголовок расширения Fragment имеет флаг M , установленный в 1 (что указывает на то, что за ним следуют дополнительные фрагменты), за исключением последнего, флаг которого установлен в 0 . Длина каждого фрагмента кратна 8 октетам, за исключением, возможно, последнего фрагмента.
Заголовки для каждого фрагмента исторически назывались «нефрагментируемой частью», имея в виду возможность фрагментации остальной части заголовка до 2014 года. Теперь никакие заголовки на самом деле не являются фрагментируемыми. [21]
Исходный пакет повторно собирается принимающим узлом путем сбора всех фрагментов и размещения каждого фрагмента по указанному смещению и отбрасывания заголовков расширения фрагмента пакетов, которые их перенесли. Пакеты, содержащие фрагменты, не обязательно должны прибывать последовательно; они будут переставлены принимающим узлом.
Если не все фрагменты получены в течение 60 секунд после получения первого пакета с фрагментом, повторная сборка исходного пакета прекращается и все фрагменты отбрасываются. Если был получен первый фрагмент (который содержит фиксированный заголовок) и один или несколько других отсутствуют, сообщение о превышении времени ( ICMPv6 тип 3, код 1) возвращается узлу, отправителю фрагментированного пакета.
Когда узел повторной сборки обнаруживает фрагмент, который перекрывается с другим фрагментом, повторная сборка исходного пакета прерывается и все фрагменты отбрасываются. Узел может опционально игнорировать точные дубликаты фрагмента вместо того, чтобы рассматривать точные дубликаты как перекрывающиеся друг друга. [1]
Хосты-получатели должны приложить все усилия для повторной сборки фрагментированных IP-датаграмм, которые после повторной сборки содержат до 1500 байт. Хостам разрешено предпринимать попытки собрать фрагментированные дейтаграммы размером более 1500 байт, но им также разрешено молча отбрасывать любую дейтаграмму после того, как становится очевидно, что повторно собранный пакет будет иметь размер более 1500 байт. Поэтому отправителям следует избегать отправки фрагментированных IP-дейтаграмм с общим повторно собранным размером более 1500 байт, если только они не знают, что получатель способен повторно собрать такие большие датаграммы.
Исследования показали, что использование фрагментации можно использовать для обхода контроля сетевой безопасности. В результате в 2014 году прежнее разрешение на переполнение цепочки заголовков IPv6 за пределами первого фрагмента было запрещено, чтобы избежать некоторых очень патологических случаев фрагментации. [21] Кроме того, в результате исследования обхода Router Advertisement Guard, [22] использование фрагментации с помощью Neighbor Discovery признано устаревшим, а использование фрагментации с Secure Neighbor Discovery (SEND) не рекомендуется. [23]
Тип 0: злой механизм...