Пакет IPv6
IPv6-пакет (англ. IPv6 packet) — блок информации, форматированный для передачи через компьютерные сети, поддерживающие протокол IPv6.
Пакеты состоят из управляющей информации, необходимой для доставки пакета адресату и полезных данных, которые требуется переслать. Управляющая информация делится на содержащуюся в основном фиксированном заголовке и содержащуюся в одном из необязательных дополнительных заголовков. Полезные данные — это, как правило, дейтаграмма или фрагмент протокола более высокого транспортного уровня, но могут быть и данные сетевого уровня (например, ICMPv6) или же канального уровня (например, OSPF).
IPv6-пакеты обычно передаются с помощью протоколов канального уровня таких как Ethernet, который инкапсулирует каждый пакет в кадр. IPv6-пакет может быть также передан с помощью туннельного протокола более высокого уровня, например, с помощью 6to4 или Teredo.
В отличие от IPv4 маршрутизаторы не фрагментируют IPv6-пакеты в ситуациях, когда пакет больше MTU подключения и узлам настоятельно рекомендуется[1] реализовать механизм Path MTU discovery для определения размера MTU пути. Иначе им придётся использовать минимально допустимый в IPv6-сетях MTU, равный 1280 октетам. Конечные узлы могут фрагментировать пакет перед отправкой, если он больше, чем MTU пути.
Фиксированный заголовок
Фиксированный заголовок IPv6-пакета состоит из 40 октетов (320 бит)[1] и имеет следующий формат:
| Отступ в октетах | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Отступ в битах | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Version | Traffic Class | Flow Label | |||||||||||||||||||||||||||||
| 4 | 32 | Payload Length | Next Header | Hop Limit | |||||||||||||||||||||||||||||
| 8 | 64 | Source Address | |||||||||||||||||||||||||||||||
| C | 96 | ||||||||||||||||||||||||||||||||
| 10 | 128 | ||||||||||||||||||||||||||||||||
| 14 | 160 | ||||||||||||||||||||||||||||||||
| 18 | 192 | Destination Address | |||||||||||||||||||||||||||||||
| 1C | 224 | ||||||||||||||||||||||||||||||||
| 20 | 256 | ||||||||||||||||||||||||||||||||
| 24 | 288 | ||||||||||||||||||||||||||||||||
Описание полей:
- Version: версия протокола; для IPv6 это значение равно 6 (значение в битах — 0110).
- Traffic Class: приоритет пакета (8 бит). Это поле состоит из двух значений. Старшие 6 бит используются DSCP для классификации пакетов.[2][3] Оставшиеся два бита используются ECN для контроля перегрузки.[4]
- Flow Label: метка потока.
- Payload Length: (16 бит) размер данных в октетах, не включая данный заголовок, но включая все расширенные заголовки.
- Next Header: задаёт тип расширенного заголовка (англ. IPv6 extension), который идёт следующим. В последнем расширенном заголовке поле Next Header задаёт тип транспортного протокола (TCP, UDP и т. д.)
- Hop Limit: аналог поля time to live в IPv4 (8 бит).
- Source Address и Destination Address: адрес отправителя и получателя соответственно; по 128 бит.
С целью повышения производительности и с расчётом на то, что современные технологии канального и транспортного уровней обеспечивают достаточный уровень обнаружения ошибок,[5] заголовок не имеет контрольной суммы.
Расширенные заголовки (англ. Extension headers)
Расширенные заголовки содержат дополнительную информацию и размещены между фиксированным заголовком и заголовком протокола более высокого уровня[1]. Тип первого расширенного заголовка указывается в поле Next Header фиксированного заголовка, а каждый расширенный заголовок имеет аналогичное поле в котором хранится тип следующего расширенного заголовка. В поле Next Header последнего заголовка находится тип протокола более высокого уровня, находящегося в качестве полезных данных.
Каждый расширенный заголовок должен иметь размер в октетах, кратный 8. Некоторые заголовки необходимо расширить до нужного размера.
Расширенные заголовки должны быть обработаны только конечным узлом, за исключением заголовка Hop-By-Hop Options, который должен быть обработан каждым промежуточным узлом на пути пакета, включая отправителя и получателя. Если расширенных заголовков в пакете несколько, то рекомендуется отсортировать их как указано в таблице ниже. Отметим, что все расширенные заголовки являются необязательными и не должны появиться в пакете более одного раза, за исключением заголовка Destination Options, который может появиться дважды.
Если узел не может обработать какой-то расширенный заголовок, то он должен отбросить пакет и отправить сообщение Parameter Problem (ICMPv6 тип 4, код 1). Если в поле Next Header расширенного заголовка будет 0, то узел должен сделать то же самое.
| Расширенный заголовок | Тип | Описание |
|---|---|---|
| Hop-by-Hop Options | 0 | Параметры, которые должны быть обработаны каждым транзитным узлом. |
| Destination Options | 60 | Параметры которые должны быть обработаны только получателем. |
| Routing | 43 | Позволяет отправителю определять список узлов, которые пакет должен пройти. |
| Fragment | 44 | Заголовок содержит информацию по фрагментации пакета. |
| Authentication Header (AH) | 51 | Содержит информацию, используемую для аутентификацию большей части пакета. См. IPsec. |
| Encapsulating Security Payload (ESP) | 50 | Осуществляет шифрование данных для безопасных подключений. См. IPsec. |
Hop-by-hop Options и Destination Options
Расширенный заголовок Hop-by-hop Options нужен для передачи дополнительных опций, обрабатываемых каждым узлом на пути пакета, включая отправителя и получателя. Расширенный заголовок Destination Options нужен для передачи дополнительных опций конечному узлу или узлам. Формат заголовка у обоих расширенных заголовков одинаков.
| Отступ в октетах | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Отступ в битах | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Next Header | Hdr Ext Len | Options | |||||||||||||||||||||||||||||
- Next Header (8 бит): Тип следующего расширенного заголовка или тип протокола, передаваемого в качестве полезных данных.
- Hdr Ext Len (8 бит): Размер заголовка в восьми-октетных блоках, исключая первый блок.
- Options: Поле переменной длины, хранящее одну или несколько опций в формате TLV (Type-Length-Value).
TLV-кодированные опции
| Отступ в октетах | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Отступ в битах | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Option Type | Opt Data Len | Option Data | |||||||||||||||||||||||||||||
- Option Type (8 бит): Тип опции. Старшие два бита указывают, что делать, если узел не может распознать опцию:
- 0 (00) — Пропустить эту опцию и продолжить обработку заголовка.
- 1 (01) — Отбросить пакет.
- 2 (10) — Отбросить пакет и отправить сообщение Parameter Problem (ICMPv6 тип 4 код 2) даже если пакет направлен на групповой адрес.
- 3 (11) — Отбросить пакет и отправить сообщение Parameter Problem (ICMPv6 тип 4 код 2) только если пакет направлен не на групповой адрес.
- Opt Data Len (8 бит): Длина поля Option Data в октетах.
- Option Data: Поле переменной длины, хранящее данные указанного типа.
Routing
Расширенный заголовок Routing используется для указания списка транзитных узлов, через которые должен пройти пакет перед тем, как попасть к получателю.
| Отступ в октетах | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Отступ в битах | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Next Header | Hdr Ext Len | Routing Type | Segments Left | ||||||||||||||||||||||||||||
| 4 | 32 | Type-specific Data | |||||||||||||||||||||||||||||||
- Next Header (8 бит): Тип следующего расширенного заголовка или тип протокола, передаваемого в качестве полезных данных.
- Hdr Ext Len (8 бит): Размер заголовка в восьми-октетных блоках, исключая первый блок.
- Routing Type (8 бит): Подтип заголовка.
- Segments Left (8 bits): Количество ещё не посещенных узлов из списка.
- Type-specific Data: Поле переменной длины, конкретный формат поля зависит от содержимого поля Routing Type.
Подтипы заголовка Routing
Подтип заголовка 0 является устаревшим в связи с тем, что заголовок может использоваться для организации DoS-атаки[6]. Если значение поля Segments Left равно нулю, то узел должен игнорировать расширенный заголовок Routing и приступить к обработке следующих расширенных заголовков. Если значение поля Segments Left не равно нулю, то узел должен отбросить пакет и отправить сообщение Parameter Problem (ICMPv6 тип 4, код 0).
Fragment
Для того чтобы отправить пакет, размер которого превышает MTU пути, отправитель разбивает пакет на фрагменты. Расширенный заголовок Fragment содержит информацию, необходимую для сборки получателем оригинального (нефрагментированного) пакета.
| Отступ в октетах | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Отступ в битах | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Next Header | Reserved | Fragment Offset | Res | M | |||||||||||||||||||||||||||
| 4 | 32 | Identification | |||||||||||||||||||||||||||||||
- Next Header (8 бит): Тип следующего расширенного заголовка или тип протокола, передаваемого в качестве полезных данных.
- Reserved (8 бит): Зарезервировано, должно быть инициализировано нулём.
- Fragment Offset (13 бит): Смещение фрагмента в восьми-октетных блоках относительно начала фрагментируемой части пакета.
- Res (2 бита): Зарезервировано, должно быть инициализировано нулём.
- M (1 бит): Будут ли ещё фрагменты. Если 0, то это последний фрагмент.
- Identification (32 бита): Число, идентифицирующее оригинальный пакет.
Полезные данные
За фиксированным и расширенными заголовками находятся полезные данные протокола транспортного уровня, например TCP-сегмент или UDP-дейтаграмма. Поле Next Header последнего IPv6-заголовка указывает тип полезных данных, хранимых в пакете.
Обычная длина полезных данных
Поле фиксированного заголовка Payload Length имеет размер 16 бит, поэтому максимально возможный размер полезных данных и расширенных заголовков равен 65535 октетам. Максимальный размер фрейма многих протоколов канального уровня гораздо меньше.
Джамбограммы
IPv6-пакет может нести больше данных с помощью опции jumbo payload в расширенном заголовке Hop-By-Hop Options[7]. Эта опция позволяет обмениваться пакетами с размером полезных данных на 1 байт меньшим чем 4 ГиБ (232 − 1 = 4294967295 байт). Пакет с таким содержимым называют джамбограммой.
Так как протоколы TCP и UDP оба имеют поля длины, ограниченные 16 битами, для поддержки джамбограмм требуется реализация модифицированных протоколов транспортного уровня. Джамбограммы могут работать только на подключениях с MTU, большим чем 65583 октетов (более 65 535 октетов для полезных данных, 40 октетов для фиксированного заголовка и 8 октетов для расширенного заголовка Hop-By-Hop Options).
Фрагментация
IPv6-пакеты никогда не фрагментируются маршрутизаторами. Пакеты, чей размер превышает MTU сетевого подключения уничтожаются и отправителю посылается сообщение Packet too Big (ICMPv6 тип 2). Подобное поведение в IPv4 происходит, если установлен бит Don’t Fragment.
Ожидается, что конечные IPv6-узлы выполнят Path MTU discovery для определения максимально допустимого размера отправляемых пакетов, и протокол более высокого уровня ограничит размер пакета. Однако если протокол более высокого уровня не в состоянии сделать этого, отправитель может использовать расширенный заголовок Fragment для выполнения фрагментации IPv6-пакетов. Все протоколы, передающие через себя IPv6-пакеты, должны иметь MTU равный или больший 1280 октетов. Протоколы, не способные передать пакет длиной 1280 октетов одним блоком, должны произвести фрагментацию и сборку самостоятельно, не затрагивая уровень IPv6[1].
Фрагментирование
Пакет, содержащий фрагмент оригинального (большого) пакета, состоит из двух частей: нефрагментируемая часть оригинального пакета, одинаковая для всех фрагментов, и фрагментируемая часть, идентифицируемая по смещению фрагмента.
Нефрагментируемая часть пакета состоит из фиксированного заголовка и расширенных заголовков оригинального пакета (опционально).
Значение поля Next Header последнего заголовка нефрагментируемой части должно быть равным 44, обозначающее, что следующим заголовком будет Fragment. В заголовке Fragment поле Next Header должно быть равно типу первого заголовка фрагментируемой части. После заголовка Fragment следует фрагмент оригинального пакета. Размер каждого фрагмента фрагментируемой части должен быть кратен 8, исключение составляет последний фрагмент.
Сборка фрагментов
Принимающий узел, собрав все фрагменты, отбрасывает расширенный заголовок Fragments и размещает фрагменты по смещениям, указанным в поле Fragment Offset, умноженным на 8. Пакеты, содержащие фрагменты, не обязаны приходить в правильном порядке, и они будут переставлены принимающим узлом, если потребуется.
Если спустя 60 секунд после получения первого фрагмента были собраны не все фрагменты, то сборка оригинального пакета отменяется и все полученные фрагменты отбрасываются. Если при этом получен первый фрагмент (с полем Fragmant Offset равным нулю), то отправителю фрагментированного пакета посылается сообщение Fragment Reassembly Time Exceeded (ICMPv6 тип 3 код 1).
Максимальный размер оригинального пакета не должен превышать 65 535 октетов, а если после сборки оригинальный пакет оказывается больше, то он должен быть отброшен.
Примечания
- Internet Protocol, version 6 (IPv6) Specification. RFC 2460.
- Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474.
- New Terminology and Clarifications for DiffServ. RFC 3260.
- The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168.
- Technical Criteria for Choosing IP The Next Generation (IPng). RFC 1726.
- Deprecation of Type 0 Routing Headers in IPv6. RFC 5095
- IPv6 Jumbograms. RFC 2675