
- •Содержание
- •1. Введение. Предпосылки появления iPv6 …………………………………………… 3
- •2. АдресацияPv6.......................................................................................................................... 4
- •3. Формат iPv6-дейтаграмм......................................................................................................14
- •4. Заключение............................................................................................................................31
- •1. Введение.
- •2.1 Представление адресов в iPv6
- •2.2 Типы адресов
- •2.3 Unicast-адреса
- •IPv6 адреса с вложенными iPv4 адресами
- •IPv4-compatible addresses
- •IPv4-mapped addresses
- •2.5 Multicast-адреса
- •2.6 Доля адресов в адресном пространстве
- •3.1 Основные изменения в дейтаграмме iPv6
- •3.2 Общая структура iPv6 дейтаграммы
- •3.3 Формат основного заголовка iPv6
- •3.4 Конкатенация заголовков iPv6 при помощи поля Next Header
- •3.5 Заголовки расширения, содержащие опции
- •3.6 Заголовок маршрутизации
- •3.7 Размер и фрагментация iPv6-дейтаграмм
- •3.9 Протокол обеспечения конфиденциальности
- •1. Вычисление и размещение esp Header
- •2. Вычисление и размещение esp Trailer
- •3. Вычисление и размещение esp Authentication Field
- •3.10 Возможные схемы шифрования и аутентификации
- •4. Заключение
- •4.1 IPv6 в мире и в России
- •4.2 Выводы и итоги
- •IPv6 has a bright future. The question is when, not if. The when begins now.
- •Список использованных источников
3.6 Заголовок маршрутизации
Этот заголовок используется в IPv6 для осуществления маршрутизации от источника.
Название поля |
Размер (байт) |
Описание |
Next Header |
1 |
Содержит тип следующего заголовка или тип вышележащего про-токола. Используется, как было описано выше, для соединения за-головков. |
Hdr Ext Len |
1 |
Длина заголовка маршрутизации в 8-байтовых единицах, не вклю-чая первые 8 байт заголовка. Для Routing Type, равному 0, эта вели-чина равно удвоенному числу адресов, включенных в заголовок. |
Routing Type |
1 |
Определяет тип маршрутизации. В настоящее время используется только значение, равное 0. |
Segments Left |
1 |
Определяет количество узлов (чьи адреса заданы в заголовке), кото-рое осталось посетить на данном маршруте. |
Reserved |
4 |
Зарезервировано. |
Address1 … AddressN |
переменный |
Набор IPv6-адресов, определяющих маршрут дейтаграммы. |
3.7 Размер и фрагментация iPv6-дейтаграмм
Наиболее важные отличия между IPv4 и IPv6 относительно размер дейтаграмм, MTU, фрагмента-ции и сборки:
o Увеличен минимальный размер MTU: в IPv4 минимальный размер MTU, который был обязан обрабатываться маршрутизаторы и поддерживаться физическими связями был 576 байт. В IPv6, все связи должны поддерживать дейтаграммы из 1280 байт. Это увеличение размера почти в два раза увеличивает эффективность передачи путем улучшения отноше-ния «полезная нагрузка / длина заголовка» и уменьшения частоты случаев, когда требуется фрагментация.
o Отказ от фрагментации в пути: в IPv4, дейтаграммы могут подвергаться фрагментации как на узле-отправителе, так и промежуточных устройствах во время их доставки. В IPv6 может осуществлять фрагментацию только узел-отправитель. Он должен заранее разбить дейтаграмму на части размером не превышающие минимальный MTU, встречающийся на пути.
o Возможность узнать о превышении размера MTU: так как маршрутизаторы не могут фрагментировать дейтаграммы, они должны отбрасывать их, если их размер превышает MTU исходящего интерфейса. Процесс обратной связи осуществляется с помощью ICMPv6, который позволяет маршрутизаторам сообщить узлу-отправителю, что он исполь-зует слишком большие для данного маршрута дейтаграммы.
o Определение MTU пути: этот механизм (Path MTU Discovery), введенный в IPv4 и усо-вершенствованный в IPv6, позволяет узлам-отправителям определить подходящий размер фрагментов.
o Перемещение полей в заголовок фрагментации: чтобы отразить уменьшившуюся необ-ходимость фрагментации, поля, которые имели постоянное место в заголовке IPv4, в IPv6 перемещены в заголовок фрагментации и используются только в случае необходимости.
Заголовок фрагментации
Это заголовок включается во фрагментированные дейтаграммы и хранит информацию, необхо-димую для их сборки.
Название по-ля |
Размер (байт) |
Описание |
Next Header |
1 |
Содержит тип следующего заголовка или тип вышележащего протоко-ла. Используется, как было описано выше, для соединения заголовков. |
Reserved |
1 |
Зарезервировано. |
Fragment Offset |
13/8 (13 бит) |
Определяет смещение фрагмента, относительно начала фрагментиро-ванных данных. Задаётся в 8-байтовых единицах и используется таким же образом, как и поле с таким же названием в заголовке IPv4. |
Res |
1/4 (2 бита) |
Зарезервировано. |
More Frag-ments Flag |
1/8 (1 бит) |
Используется таким же образом, как поле с таким же названием в за-головке IPv4 – когда флаг установлен в 0, это говорит о том, что это последний фрагмент в сообщении. Когда флаг установлен в 1 – это значит, что за этим фрагментом следуют ещё другие. |
Identification |
4 |
Используется таким же образом, как поле с таким же названием в за-головке IPv4, но расширено до 32 бит. Содержит значение, одинаковое для всех фрагментов, относящихся к одному сообщению – использует-ся для того, чтобы не соединялись вместе фрагменты из разных сооб-щений. |
3.8 Протокол аутентификации [RFC 2402]
Одним из двух ключевых протоколов IPSec является протокол аутентификации (Authentication Header or AH). Этот протокол позволяет аутентифицировать (т.е. проверить подлинность) все или некоторые поля дейтаграммы путем добавления заголовка, вычисляемого на основе значений этих полей. То, какие поля будут использоваться в вычислении, и расположение заголовка зависит от установленного режима – туннельного или транспортного.
Перед началом обмена между устройствами устанавливается контекст безопасности (Security Association or SA). Например, по алгоритму обмена ключами Диффи-Хеллмана, генерируется сек-ретный ключ, известный только отправителю и получателю.
После этого протокол AH вычисляет некоторое значение (хэш-сумму) на основе значений полей и секретного ключа. Это значение называется «код проверки целостности» (Integrity Check Value or ICV), оно помещается в специальный заголовок и передается получателю. Получатель производит те же вычисления, используя тот же ключ, что позволяет при несовпадении ICV о повреждении или изменении злоумышленником исходной дейтаграммы.
Присутствие заголовка аутентификации позволяет нам проверить целостность дейтаграммы, но сами данные не шифруются, то есть AH не обеспечивает конфиденциальность.
В транспортном режиме AH размещается как заголовок расширения перед заголовками Destina-tion Options и ESP (о нём см. далее), но после всех остальных. В туннельном режиме он находится в IP-дейтаграмме, которая инкапсулирует исходную.
Формат дейтаграмм с заголовком аутентификации
Формат заголовка аутентификации
Название поля |
Размер (байт) |
Описание |
Next Header |
1 |
Содержит тип следующего заголовка или тип вышележащего протокола. Используется, как было описано выше, для соедине-ния заголовков. |
Payload Length |
1 |
Несмотря на своё название, это поле содержит размер заголовка аутентификации в 4-байтовых единицах, за исключением первых 8-и байт. |
Reserved |
2 |
Зарезервировано. |
Security Parame-ter Index (SPI) |
4 |
32-битное значение, которое вместе с адресом получателя, а также типом протокола безопасности, используемого в AH, идентифицирует контекст безопасности, используемый для данной дейтаграммы. |
Sequence Number |
4 |
Это поле инициализируется нулем при формировании контекста безопасности (SA) и увеличивается на единицу для каждой дей-таграммы, посылаемой в этом SA. Это уникальным образ иден-тифицирует каждую дейтаграмму в пределах SA и используется для защиты от атаки путем перепосылки перехваченных дейта-грамм. |
Authentication Data |
переменный |
Содержит результат вычисления хэш-функции, используемой протоколом AH - код проверки целостности (ICV). |