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 >[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, то это последний фрагмент.
- > Полезные данные [ править | править код ]
За фиксированным и расширенными заголовками находятся полезные данные протокола транспортного уровня, например TCP-сегмент или UDP-дейтаграмма. Поле Next Header последнего IPv6-заголовка указывает тип полезных данных, хранимых в пакете.
Обычная длина полезных данных [ править | править код ]
Поле фиксированного заголовка Payload Length имеет размер 16 бит, поэтому максимально возможный размер полезных данных и расширенных заголовков равен 65535 октетам. Максимальный размер фрейма многих протоколов канального уровня гораздо меньше.
Джамбограммы [ править | править код ]
IPv6-пакет может нести больше данных с помощью опции jumbo payload в расширенном заголовке Hop-By-Hop Options [7] . Эта опция позволяет обмениваться пакетами с размером полезных данных на 1 байт меньшим чем 4 ГиБ (2 32 − 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 октетов, а если после сборки оригинальный пакет оказывается больше, то он должен быть отброшен.
При разработке протокола IPv6 были внесены изменения в формат IP-пакета. Увеличение размера IPv6-адреса с 32 бит до 128 бит добавило 24 байта к заголовку пакета, что, в свою очередь, привело к попытке уменьшить его размер за счет исключения полей, связанных с фрагментацией, и поля контрольной суммы. В результате заголовок пакета IPv6 увеличился всего в два раза.
Пакет протокола IPv6 состоит из фиксированного заголовка и произвольного числа расширенных заголовков. Такой порядок способствует эффективной обработке пакетов на всем пути их следования. Фиксированный заголовок состоит из 40 байт и имеет формат, показанный на рисунке 6.19.
Рис. 6.19. Сравнение форматов заголовка IPv4 и IPv6
Заголовок IPv6-пакета состоит из следующих полей:
· Версия (Version) – для IPv6 значение поля должно быть равно 6;
· Класс трафика (Traffic Class) – поле приоритета пакета;
· Метка потока (Flow Label) – используется отправителем для обозначения последовательности пакетов, которые должны быть подвергнуты определенной обработке маршрутизаторами;
· Размер поля данных (Payload Length) – число, указывающее длину поля данных, идущего за заголовком пакета (с учетом расширенного заголовка);
· Следующий заголовок (Next Header) – задает тип расширенного заголовка IPv6, который следует за фиксированным;
· Предельное число шагов (Hop Limit) – уменьшается на 1 каждым маршрутизатором, через который передается пакет; при значении, равном 0, пакет отбрасывается;
· Адрес источника (Source Address) – 128-битный адрес отправителя пакета;
· Адрес назначения (Destination Address) – 128-битный адре получателя пакета. Сравнение заголовка пакета IPv4 с заголовком IPv6 показывает что:
поле Длина заголовка (Internet Header Length) исчезло, так как фиксированный заголовок IPv6 имеет определенную длину (40 байт);
· поле Тип сервиса (Type of Service) трансформировалось в заголовке IPv6 в поля Класс трафика (Traffic Class) и Метка потока (Flow Label);
· поля Время жизни (Time to Live) и Протокол (Protocol) в заголовке IPv6 изменили названия, соответственно, на Предельное число шагов (Hop Limit) и Следующий заголовок (Next Header) с некоторым уточнением трактовки;
· поле Контрольная сумма (Header Checksum) было ликвидировано, так как её подсчёт занимает некоторое время, что существенно снижает производительность узлов;
· поля в заголовке IPv4, связанные с фрагментацией были перенесены в расширенные заголовки IPv6;
· минимальный размер пакета, который должен передаваться в сетях IPv6 без фрагментации, увеличен с 576 до 1 280 байт.
Расширенные заголовки IPv6 используются для поддержки механизмов безопасности, фрагментации, сетевого управления и расположены между фиксированным заголовком и заголовком протокола более высокого уровня. Пакет IPv6 может содержать 0, 1 или несколько расширенных заголовков, каждый из которых идентифицируется значением поля Next Header предшествующего заголовка. Все существующие типы расширенных заголовков описаны в таблице 8.
Таблица 8 Типы расширенных заголовков IPv6
| Расширенный заголовок | Тип | Описание |
| Hop-by-Hop Options | Параметры, которые должны быть обработаны каждым транзитным узлом на пути от отправителя до получателя пакета | |
| Routing | Позволяет отправителю определять список узлов, которые пакет должен пройти | |
| Fragment | Содержит информацию о фрагментации пакета | |
| Authentication Header (AH) | Содержит информацию для проверки подлинности зашифрованных данных при использовании IPSec | |
| Encapsulating Security Payload (ESP) | Обеспечивает шифрование данных с помощью IPSec | |
| Destination Options | Определяет произвольный набор опций, которые должны быть обработаны получателем пакета |
Поле Next Header используется для логической связи всех заголовков пакета IPv6, например, Next Header в фиксированном заголовке указывает тип первого расширенного заголовка, поле Next Header в первом расширенном заголовке содержит тип следующего расширенного заголовка и т.д. Поле Next Header последнего расширенного заголовка содержит номер протокола транспортного уровня (TCP или UDP) (рис. 6.20).
Рис. 6.20. Расширенные заголовки IPv6
Расширенные заголовки обрабатываются только узлом-получателем, за исключением заголовка Hop-By-Hop Options, который обрабатывается каждым промежуточным узлом на пути пакета, включая отправителя и получателя.
Не нашли то, что искали? Воспользуйтесь поиском:
Лучшие изречения: Для студента самое главное не сдать экзамен, а вовремя вспомнить про него. 10074 — 
| 7514 — 
или читать все.
78.85.5.224 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.
Отключите adBlock!
и обновите страницу (F5)
очень нужно
Рис.1.1. Формат заголовка IPv6-пакета
Заголовок IPv6-пакета включает следующие поля:
1) «Версия IP-протокола» (Version):
4-битовое поле, содержащее значение «6».
2) «Класс трафика» (Traffic Class):
8-битовое поле «Класс трафика» в составе IPv6-заголовка может использоваться узлом/отправителем и/или узлом/ретранслятором (маршрутизатором) для идентификации и распознавания IPv6-пакетов, с точки зрения их принадлежности к различным классам или по их приоритетам. В момент написания данного стандарта, проводилось несколько экспериментов по использованию специализированных битов, определяющих «Тип обслуживания» и/или «Приоритет», для обеспечения различных форм дифференцированного обслуживания IPv4-пакетов, которые не использовали в явном виде маркеры потоков. Поле «Класс трафика» в составе IPv6-заголовка призвано обеспечить аналогичную функциональность IPv6-протокола.
К использованию поля «Класс трафика» предъявляются следующие общие требования:
- Программный IPv6-модуль IPv6-узла должен иметь специализированный прикладной интерфейс, через который прикладной процесс будет указывать тип обслуживания формируемого им трафика. Далее этот тип обслуживания будет указываться в поле «Класс трафика» IPv6-заголовка. В режиме «по-умолчанию» это поле (все 8 битов) должно заполняться нулями.
- IPv6-узлы, функционально способные использовать несколько или все биты поля «Класс трафика», могут изменять значения этих битов поля в IPv6-пакетах, которые они передают ретранслируют или получают, в соответствие со спецификой их применения. А тем IPv6-узлам, которые не способны использовать поле «Класс трафика», рекомендуется игнорировать это поле и оставлять его без изменений.
- Протокол верхнего уровня не должен в обязательном порядке сравнивать значения битов этого поля в принятом пакете с аналогичными битами в отправленном источником пакете.
3) «Маркер потока» (Flow Label):.
20-битовое поле «Маркер потока» («Flow Label») в составе IPv6-заголовка может использоваться отправителем для маркирования последовательностей пакетов, которым требуется специальная обработка IPv6-маршрутизаторами, например, обработка в режиме «не по умолчанию» («non-default quality of service») или обслуживание в масштабе реального времени («real-time»). Этот аспект IPv6-протокола, на момент написания данного стандарта, находился по-прежнему на стадии эксперимента и анализа, и поэтому в дальнейшем станет более очевидным весь набор требований к маркеру потока и его применению. Серверы и маршрутизаторы, которые не поддерживают функцию маркирования потока, должны это поле заполнять нулями, когда пакет направляется на передачу в канал связи, передавать его дальше без изменений при ретрансляции пакета, и игнорировать при получении пакета.
4) «Размер поля полезной нагрузки» (Payload Length):
16-битовое беззнаковое целое число, которое указывает на размер поля полезной нагрузки в октетах, следующего сразу после заголовка (включая заголовки расширения).
5) «Следующий заголовок» (Next Header):
8-битовый определитель, который указывает на тип заголовка, следующего сразу за этим заголовком.
6) «Число ретрансляций» (Hop Limit):
8-битовое беззнаковое целое число, которое указывает на максимальное число ретрансляционных участков. Это число уменьшается на единицу каждым IP-узлом, через который проследовал IPv6-пакет. Если это поле содержит нулевое значение, то тогда IPv6-пакет уничтожается.
7) «Адрес отправителя пакета» (Source Address):
128-битовый адрес отправителя пакета.
8) «Адрес получателя пакета» (Destination Address):
128-битовый адрес конечного получателя пакета, то есть которому предназначен данный пакет. (Однако, возможно это — не самый последний получатель, если в IPv6-пакете представлен заголовок маршрутизации.)
Дополнительные заголовки
В опущенных полях заголовка иногда возникает необходимость‚ поэтому в протоколе IPv6 была представлена новая концепция (необязательного) дополнительного заголовка. На сегодня определены шесть типов дополнительных заголовков, которые перечислены в таблице 1. Все они являются необязательными, но в случае использования более чем одного дополнительного заголовка они должны располагаться сразу за фиксированным заголовком, желательно в указанном порядке.
Табл. 1. Типы дополнительных заголовков IPv6
У некоторых заголовков формат фиксированный, другие содержат переменное количество полей переменной длины. Для них каждый пункт кодируется в виде тройки (Тип, длина, Значение). Тип представляет собой однобайтовое поле, содержащее код параметра. Первые два бита этого поля сообщают, что делать с пакетом, маршрутизаторам, не знающим, как обрабатывать данный параметр. Возможны четыре следующих варианта: пропустить параметр, игнорировать пакет, игнорировать пакет и отослать обратно ICMP-пакет, а также то же самое, что и предыдущий вариант, но не отсылать обратно ICМР -пакет в случае многоадресной рассылки (чтобы один неверный многоадресный пакет не породил миллионы ICМР -донесений).
Поле Длина также имеет размер 1 байт. Оно сообщает, насколько велико значение (от 0 до 255 байт). Поле Значение содержит необходимую информацию, размером до 255 байт.
Заголовок параметров маршрутизации содержит информацию, которую должны исследовать маршрутизаторы на протяжении всего пути следования пакета. Пока что был определен один вариант использования этого параметра: поддержка дейтаграмм, превышающих 64 Кбайт. Формат заголовка показан на рисунке 1.2.
.png)
Рис. 1.2. Дополнительный заголовок для больших дейтаграмм
Как и все дополнительные заголовки, он начинается с байта, означающего тип следующего заголовка. Следующий байт содержит длину положительного заголовка в байтах, не считая первых 8 байт, являющихся обязательными. С этого начинаются все расширения.
Следующие два байта указывают, что данный параметр содержит размер дейтаграммы (код 194) в виде 4-байтового числа. Размеры меньше 65 536 не допускаются, так как могут привести к тому, что первый же маршрутизатор проигнорирует данный пакет и отошлет обратно ICМР-сообщение об ошибке. Дейтаграммы, использующие подобные расширения заголовка, называются джамбограммами (от слова ‹jumbo›, означающего нечто большое и неуклюжее). Использование джамбограмм важно для суперкомпьютерных приложений, которым необходимо эффективно передавать по Интернету гигабайты данных.
Маршрутный заголовок содержит информацию об одном или нескольких маршрутизаторах, которые следует посетить по пути к получателю. Это очень сильно напоминает свободную маршрутизацию стандарта IPv4 тем, что указанные в списке маршрутизаторы должны быть пройдены строго по порядку, тогда как не указанные проходятся между ними. Формат маршрутного заголовка показан на рисунке 1.3.
Рис. 1.3. Дополнительный заголовок для маршрутизации
Первые четыре байта дополнительного маршрутного заголовка содержат четыре однобайтовых целых числа. Поля Следующий заголовок и Длина дополнительного заголовка были описаны ранее. В поле Тип маршрутизации описывается формат оставшейся части заголовка. Если он равен 0, это означает, что далее следует зарезервированное 32-разрядное слово, а за ним — некоторое число адресов IPv6. В будущем возможно, будут по мере необходимости изобретаться какие-то то новые поля. Наконец, в поле Число оставшихся сегментов указывается, сколько адресов из списка еще осталось посетить. Его значение уменьшается при прохождении каждого адреса. Когда оно достигает нуля, пакет оставляется на произвол судьбы — никаких указаний относительно его дальнейшего маршрута не дается. Обычно в этот момент пакет уже находится достаточно близко к месту назначения, и оптимальный маршрут очевиден.
Заголовок фрагментации определяет фрагментацию способом, схожим с протоколом IPv4. Заголовок содержит идентификатор дейтаграммы, номер фрагмента и бит, информирующий о том, является ли этот фрагмент последним. В отличие от IPv4, в протоколе IPv6 фрагментировать пакет может только хост-источник. Маршрутизаторы фрагментировать пересылаемые пакеты не могут. Это порывающее с философией прошлого изменение в протоколе упрощает и ускоряет работу маршрутизаторов. Как уже было сказано, маршрутизатор отвергает слишком большие пакеты, посылая в ответ IСМР-пакет, указывающий хосту-источнику на необходимость заново передать пакет, выполнив его фрагментацию на меньшие части.
Заголовок аутентификации предоставляет механизм подтверждения подлинности отправителя пакета. Шифрование данных, содержащихся в поле полезной нагрузки обеспечивает конфиденциальность: прочесть содержимое пакета сможет только тот, для кого предназначен пакет. Для выполнения этой задачи в заголовках используются криптографические методы.
2. Компьютерные сети / Таненбаум Э.С. – издательство Питер, 2003 г.
