Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

Нефрагментируемая часть включает 1Ру6-заголовок и любые другие заголовки расширения, которые должны обрабатываться 1Ру6-узлами, расположенными на маршруте следования до конеч­ ного узла/получателя, то есть все перечисленные выше заголовки, включая также заголовок расширения «Маршрутизация», если он представлен, либо заголовок «Дополнительные функции: ретранс­ ляция», если он представлен. Фрагментируемая часть включает ос­ тавшуюся последовательность 1Ру6-пакета, то есть любые заголовки расширения, которые должны обрабатываться только конечным 1Ру6-узлом/получателем, заголовок вышележащего уровня Internetархитектуры и транслируемые данные.

Фрагментируемая часть оригинального 1Ру6-пакета разбивает­ ся на фрагменты, каждый из которых имеет длину, равную целому числу 8-октетных последовательностей, за исключением, может быть, последнего фрагмента («крайний правый»). Фрагменты пере­ даются последовательно друг за другом с помощью фрагментальных 1Ру6-пакет (рис. 12.21).

Каждый фрагментальный пакет состоит из:

онефрагментируемой части оригинального 1Ру6-пакета с полем «Размер поля полезной нагрузки» из оригинального IPv6заголовка, в котором отбрасывается значение поля полезной нагрузки из оригинального заголовка и включается размер по­ ля полезной нагрузки только данного фрагментального паке­ та. Кроме этого, значение в поле «Идентификатор следующего заголовка расширения» последнего заголовка расширения из нефрагментируемой части оригинального 1Ру6-пакета заменя­ ется значением «44»;

озаголовка расширения «Фрагментация», включающего:

-поле «Идентификатор следующего заголовка расширения», значение в котором указывает на первый заголовок фраг­ ментируемой части оригинального 1Ру6-пакета;

-поле «Смещение (сдвиг) данного фрагмента» («Fragment Offset») - длина (в 8-октетовых единицах) между началом фрагментируемой части исходного 1Ру6-пакета и началом данного фрагмента пакета (длина сдвига - Ль где к = О...п-l). Если имеет место первый фрагмент («крайний левый»), то данное поле заполняется нулями (см. рис. 12.21);

-поле «Флаг» («М flag»), содержащее значение «О», если дан­ ный фрагмент является последним («крайний правый»), или «1»- в противном случае;

-поле «Идентификация», содержащее идентификатор для данного оригинального 1Ру6-пакета;

Рис. 12.21. Формат «оригинального пакета», разделенного

на фрагменты, и фрагментальные пакеты

о и собственно самого фрагмента оригинального 1Ру6-пакета. Размеры фрагментов должны выбираться таким образом, чтобы

размеры сформированных фрагментальных пакетов не превышали максимально допустимый размер передаваемой единицы данных для конкретного маршрута доставки до конечного 1Ру6-узла/получателя. В 1Ру6-узле/получателе осуществляется обработка принятых фраг­ ментальных пакетов и на их основе сборка оригинального пакета в нефрагментарном (исходном) формате (рис. 12.20).

Заголовок расширения «Дополнительные функции: узелполучатель». Данный заголовок используется для доставки дополни­ тельной информации, которая должна контролироваться только IPузлом/получателем 1Ру6-пакета. Заголовок расширения «Дополни­ тельные функции: узел-получатель» идентифицируется значением «60» в поле «Идентификатор следующего заголовка расширения» за­ головка расширения, непосредственно предшествующего ему. Формат заголовка расширения «Дополнительные функции: узел-получатель» представлен на рис. 12.22. и включает следующие поля:

Д а н н ы е д опо л ни тел ьн ой ф ункции - у зел -п о л уч ател ь

Рис.12.22. Формат заголовка «Дополнительные функции:

узел-получатель»

0«Идентификатор следующего заголовка расширения» («Next Header») - 8-битовый определитель, который идентифицирует

тип заголовка расширения, следующего сразу за заголовком «Дополнительные функции: узел-получатель» (используемые значения представлены в стандарте RFC-1700);

о«Длина поля «Данные дополнительной функции: узелполучатель» («Hdr Ext Len») - 8-битовое беззнаковое целое число, которое определяет длину заголовка расширения «Данные до­ полнительной функции: узел-получатель» в 8-октетовых едини­ цах, за исключением первых восьми октетов;

в«Данные дополнительной функции: узел-получатель» («Opti­ ons») - поле переменной длины, в котором весь заголовок «До­ полнительные функции: узел-получатель» рассматривается как последовательность, состоящая из целого числа 8-октетных суб­ последовательностей.

Только в заголовке «Данные дополнительной функции: узелполучатель», представленном в этом стандарте, может использо­ ваться функция дополнения нулями двух типов «Padl» и «PadN».

Отсутствие следующего заголовка расширения. Значение «59» в поле «Идентификатор следующего заголовка» 1Ру6-заголовка или любого другого заголовка расширения указывает на то, что за этим заголовком ничего не следует (данный заголовок последний в этом пакете). Когда 1Ру6-пакет подлежит дальнейшей ретрансля­ ции, то данное поле содержит значение «59», а все финальные окте­ ты должны игнорироваться и передаваться без изменений.

12.11. Проблемы, связанные с выбором длины 1Руб-пакета

1Ру6-протокол требует, чтобы каждый Internet-канал имел MTU-параметр, равный 1280 октетам или больше. Если какая-либо линия связи не способна передавать 1280-октетные 1Ру6-пакеты це­ ликом, то тогда должен быть специальный протокол канального уровня (в Internet-архитектуре), который бы выполнял функции фрагментирования и сборки 1Ру6-пакетов.

Линии связи, в которых предусмотрена настройка MTUпараметра (например, РРР-протокол канального уровня, RFC-1661), должны устанавливать значение этого параметра, равное, по крайней мере, 1280 октетов. Тем не менее, существует рекомендация, чтобы значение MTU-параметра было равно 1500 октетов или больше с це­ лью реализации функции повторного обрамления пакета (туннелиро­ вание) без использования фрагментации пакета на сетевом (IP) уровне.

Если IP-узел подключен к нескольким линиям связи, то он дол­ жен быть способен обрабатывать поступившие пакеты, длина которых превышает канальный MTU-параметр. Стандарт RFC-1981 содержит

строгое требование: 1Ру6-узлы должны обеспечивать значение MTUпараметра более 1280 октетов. Однако, программный 1Ру6-модуль с минимальным набором функций (например, в загружаемом ПЗУ) мо­ жет запретить «самому себе» передачу пактов длиной не более чем 1280 октетов, и пренебречь требованием стандарта RFC-1981.

С целью передачи пакета длиной более чем 1280 октетов 1Ру6-узел может с помощью заголовка расширения «Фрагментация» фрагментировать пакет с последующей его сборкой у получателя(ей). Однако процедура фрагментирования является излишней для при­ кладного процесса, который способен управлять длиной своих сооб­ щений, и таким образом обеспечить необходимый MTU-параметр (т.е., «подгонять» длину к 1280 октетам).

1Ру6-узел должен быть способен фрагментировать пакет так, чтобы после его сборки, он имел длину 1500 октетов или больше. Наиболее предпочтительным для 1Ру6-узла является его способ­ ность фрагментировать пакеты, которые при их сборке превышали длину 1500 октетов.

Протокол более высокого уровня или прикладной процесс, за­ висимые от 1Ру6-фрагментирования при передаче пакетов длиной, превышающей установленный для канала связи MTU-параметр, не должны отправлять сообщения, которые требуют для их передачи формирование 1Ру6-пакетов длиной более 1500 октетов, до тех пор, пока не будет гарантии того, что узел/получатель способен соби­ рать пакеты большей длины.

Б ответ на переданный 1Ру4-узлу/получателю 1Ру6-пакет (т.е., пакет, который прошел процедуру преобразования из 1Ру6-фор- мата в 1Ру4-формат) 1Ру6-узел/отправитель может получить ICMPсообщение с кодом «Слишком большое сообщение» («Too Big mes­ sage»), указывающее, что на данном ретрансляционном участке было превышено допустимое значение MTU-параметра, состав­ ляющее менее 1280 октетов. В таком случае, 1Ру6-узлу/отправителю нет необходимости уменьшать размер последующих пакетов до значения менее 1280 октетов. Ему просто необходимо включить в эти пакеты заголовок расширения «Фрагментация» так, чтобы маршрутизатор, осуществляющий процедуру преобразования па­ кета из 1Ру6-формата в 1Ру4-формат, мог формировать подходящее значение идентификационного параметра для его использования 1Ру4-фрагментах. (.Примечание. Это означает, что размер поля по­ лезной нагрузки, возможно, придется уменьшить до 1232 октетов (1280 минус 40 для 1Ру6-заголовка и 8 для заголовка расширения «Фрагментация»), а может оно будет и менее 1232 октетов, если ис­ пользовать дополнительные заголовки расширения.)

12.12. Маркеры потоков

20-битовое поле «Маркер потока» («Flow Label») в составе IPv6заголовка может использоваться отправителем для маркирования по­ следовательностей пакетов, которым требуется специальная обработка 1Ру6-маршрутизаторами, например, обработка в режиме «не по умол­ чанию» («non-default quality of service») или обслуживание в масштабе реального времени («real-time»). Серверы и маршрутизаторы, которые не поддерживают функцию маркирования потока, должны это поле заполнять нулями, когда пакет направляется на передачу в канал свя­ зи, передавать его дальше без изменений при ретрансляции пакета, и игнорировать при получении пакета.

12.13. Классы трафика

8-битовое поле «Класс трафика» в составе 1Ру6-заголовка может использоваться узлом/отправителем и/или узлом/ретранслятором (маршрутизатором) для идентификации и распознавания IPv6-na- кетов, с точки зрения их принадлежности к различным классам или по их приоритетам. В момент написания данного стандарта, проводилось несколько экспериментов по использованию специализированных би­ тов, определяющих «Тип обслуживания» и/или «Приоритет», для обеспечения различных форм дифференцированного обслуживания 1Ру4-пакетов, которые не использовали в явном виде маркеры потоков. Поле «Класс трафика» в составе 1Ру6-заголовка по своему функцио­ нальному предназначению аналогично полям «Тип обслуживания» и/ или «Приоритет» в 1Ру4-пакетах.

К использованию поля «Класс трафика» предъявляются сле­ дующие общие требования:

1)программный 1Ру6-модуль 1Ру6-узла должен иметь специали­ зированный прикладной интерфейс, через который приклад­ ной процесс будет указывать тип обслуживания формируемо­ го им трафика. Далее этот тип обслуживания будет указывать­ ся в поле «Класс трафика» 1Ру6-заголовка. В режиме «поумолчанию» это поле (все 8 бит) должно заполняться нулями;

2)1Ру6-узлы, функционально способные использовать несколько или все биты поля «Класс трафика», могут изменять значения этих битов поля в 1Ру6-пакетах, которые они передают, ретранслируют или получают, в соответствие со спецификой их применения. А тем 1Ру6-узлам, которые не способны ис­ пользовать поле «Класс трафика», рекомендуется игнориро­ вать это поле и оставлять его без изменений;

3)протокол верхнего уровня не должен в обязательном порядке сравнивать значения битов этого поля в принятом пакете с аналогичными битами в пакете, отправленном источником.

12.14. Проблемы протоколов верхних уровней

Проверочная сумма протоколов транспортного уровня. Лю­ бой транспортный или прикладной протоколы, которые включают адреса из IP-заголовка в последовательность данных для вычисления проверочной суммы должны быть модифицированы для «работы» с 1Ру6-протоколом, и «уметь» включать в обрабатываемую последова­ тельность 128-битовые 1Ру6-адреса вместо 32-битовых 1Ру4-адресов. На рис. 12.23 представлен формат «псевдозаголовка» для TCP- и UDP-протоколов в составе 1Ру6-заголовка.

Рис. 12.23. Формат «псевдозаголовка» для TCP- и UDP-протоколов

в составе 1Ру6-заголовка

Если 1Ру6-пакет содержит заголовок расширения «Маршрути­ зация», то тогда адрес получателя пакета, используемый в псевдоза­ головке, одновременно является и адресом финального получателя пакета. На узле/отправителе этот адрес' будет в последнем элементе заголовка расширения «Маршрутизация», а на узле/ получателе этот адрес будет в поле «Адрес получателя пакета» 1Ру6-заголовка.

Значение в поле «Идентификатор следующего заголовка» псевдозаголовка идентифицирует протокол верхнего уровня (для UDP-протокола - «6», для ТСР-протокола - «17»). Это значение бу­ дет отличаться от значения в аналогичном поле 1Ру6-заголовка, если конечно имеют место иные заголовки расширения между IPv6заголовком и заголовком верхнего уровня.

Поле «Размер блока транспортного уровня» в псевдозаголовке содержит значение длины блока транспортного уровня (например, заголовок TCP-блока плюс поле полезной нагрузки TCP-блока). Не­ которые протоколы транспортного и прикладного уровней разме­ щают в своих сообщениях данные о длине (размере) этих сообщений (например, в заголовке блока UDP-протокола содержится поле «Пол­ ная длина дейтаграммы»). В случае применения таких протоколов

значение длины протокольного сообщения размещается в поле «Раз­ мер блока транспортного уровня» псевдозаголовка. Другие протоко­ лы (например, TCP-протокол) не размещают в своих сообщениях данные о длине (размере) этих сообщений. В этом случае в поле «Размер блока транспортного уровня» псевдозаголовка указывается значение, равное значению в поле «Размер поля полезной нагрузки» 1Ру6-заголовка за вычетом длины всех заголовков расширения, раз­ мещённых между 1Ру6-заголовком и заголовком верхнего уровня.

В отличие от 1Ру4-протокола, когда 1Ру6-узлом/отправителем передаются UDP-дейтаграммы, вычисление проверочных сумм этих дейтаграмм является обязательным. Другими словами, если переда­ ется UDP-пакет (то есть 1Ру6-пакет, содержащий UDP-дейтаграмму), то тогда 1Ру6-узел/отправитель должен вычислить проверочную сумму данного пакета, используя для этого последовательность ок­ тетов, в которую входят сам пакет и псевдозаголовок. Если результат вычисления оказался равным нулю, то тогда 16-битовое поле «Кон­ трольная сумма» в заголовке UDP-дейтаграммы должно заполняться единицами. 1Ру6-узлы/получатели должны уничтожать UDP-пакет, в котором поле «Контрольная сумма» заголовка UDP-дейтаграммы содержит только одни нули, и после этого они должны регистриро­ вать возникновение нештатной ситуации (ошибки).

Шестая версия ICMP-протокола (ICMPv6) включает рассмот­ ренный выше псевдозаголовок и последовательность октетов, по ко­ торой вычисляется проверочная сумма (в этом заключается одно из отличий от ICMPv4, которая не предусматривает включение псевдо­ заголовка при расчёте проверочной суммы). Причина этого заклю­ чается в том, что 1СМРу6-сообщения необходимо защитить от оши­ бочной доставки и искажения тех полей 1Ру6-заголовка, на которые оно ссылается, так как (в отличие от 1Ру4-протокола) 1Ру6-заголовок не входит в последовательность октетов, по которой вычисляется проверочная сумма сетевого уровня Internet-архитектуры. Если зна­ чение в поле «Идентификатор следующего заголовка» псевдозаго­ ловка для ICMP-протокола равно «58», то это указывает на наличие 1СМРу6-сообщения.

Максимальное «время жизни» 1Ру6-пакета. В отличие от 1Ру4-протокола, 1Ру6-узлам нет необходимости устанавливать мак­ симальное «время жизни» 1Ру6-пакета («maximum packet lifetime»). По этой причине поле «Время жизни» («Time to Live») в 1Ру4-пакете было переименовано в поле «Число ретрансляций» («Нор Limit») в 1Ру6-пакете. На практике, очень редко, если конечно нет каких-либо специальных задач, когда программные 1Ру4-модули придержива­ ются требования относительно ограничения времени существова­

ния пакета (причём такая ситуация остается практически неизмен­ ной). Любой протокол верхнего уровня, который «доверяет» сете­ вому (IP) уровню (IPv4или 1Ру6-протоколу) процедуру ограниче­ ния «времени жизни» пакета, должен дополнить набор реализуе­ мых им функций специальными процедурами выявления и унич­ тожения просроченных пакетов.

Максимальный размер поля полезной нагрузки в сообщении протокола верхнего уровня. При расчёте максимального размера поля полезной нагрузки в сообщении протокола верхнего уровня, последний должен учитывать наибольший размер 1Ру6-заголовка от­ носительно 1Ру4-заголовка. Например, в 1Ру4-протоколе существует специальная процедура расчёта максимального размера ТСР-блока (MSS - maximum segment size), в соответствие с которой этот размер рассчитывается как максимальный размер пакета (либо значение в режиме «по-умолчанию», либо значение MTU-параметра) минус 40 октетов (из которых 20 октетов для 1Ру4-заголовка минимальной длины и 20 октетов для ТСР-заголовка минимальной длины). Если TCP-протокол используется совместно с 1Ру6-протоколом, то тогда MSS должен рассчитываться как максимальный размер пакета ми­ нус 60 октетов, так как минимальный размер 1Ру6-заголовка (т.е., 1Ру6-заголовок без заголовков расширения) на 20 октетов длиннее, чем 1Ру4-заголовок минимальной длины.

Ответная реакция на принятые пакеты, содержащие заго­ ловки расширения «Маршрутизация». Если протокол верхнего уровня передает одно или несколько сообщений, преобразуемые на сетевом уровне в 1Ру6-пакеты, в ответ на принятое сообщение, пере­ данное с помощью 1Ру6-пакета, содержащего заголовок «Маршру­ тизация», то тогда ответный(е) 1Ру6-пакет(ы) не должны содержать заголовок «Маршрутизация», который был автоматически извлечен из принятого 1Ру6-пакета. Однако все сказанное выше не относится к процедурам проверки целостности и аутентификации IP-адреса узла/отправителя и заголовка «Маршрутизация» (например, на ос­ нове использования заголовка расширения «Аутентификация» в принятом пакете). Другими словами, допускается передача только следующих типов пакетов в ответ на принятый пакет, содержащий заголовок «Маршрутизация»:

• ответные пакеты, не содержащие заголовок «Маршрутизация»;

оответные пакеты, содержащие заголовок «Маршрутизация», но только не тот, который был извлечен из принятого пакета (например, заголовок «Маршрутизация», который использует­ ся для локальной настройки);

оответные пакеты, содержащие заголовок «Маршрутизация», но только тот, который был извлечен из принятого пакета уз­ лом/получателем и прошли в обязательном порядке на уз­ ле/получателе процедуры проверки целостности и аутенти­ фикации IP-адреса узла/отправителя и заголовка «Маршру­ тизация».

12.15. ICMP-протокол для IP-протокола шестой версии (RFC-4443)

1СМРу6-протокол имеет собственное обозначение в поле «Следующий заголовок» в IP-заголовке IPv6: «58». ICMPv6 использу­ ется в составе программного обеспечения 1Ру6-узлов в целях пере­ дачи сообщений, уведомляющих об ошибках, которые были обна­ ружены при обработке IP-сообщений (IP-пакетов), а также для реа­ лизации других технологических функций (например, диагности­ ческих «ping»). Программный 1СМРу6-модуль является составной частью 1Ру6-модуля и должен обязательно присутствовать в каждом 1Ру6-узле.

Общий формат сообщений. 1СМРу6-сообщения можно раз­ делить на два класса:

•сообщения об ошибках;

•информационные сообщения.

Сообщения об ошибках отличаются тем, что в поле «Тип со­

общения» старший бит имеет нулевое значение. Таким образом, со­ общения об ошибках могут иметь в поле «Тип сообщения» значения 0.. .127, а информационные - 128.. .255.

Существуют следующие 1СМРу6-сообщения:

Сообщения об ошибках

«1» - узел назначения не достижим;

«2» - размер IP-пакета слишком большой; «3» - превышение времени; «4» - параметрическая проблема;

Информационные сообщения

«128» - запрашивающий эхо-пакет; «129» - ответный эхо-пакет.

Каждому 1СМРу6-сообщению предшествует 1Ру6-заголовок и может быть один или несколько (или не быть вообще) ГРуб-заголовков расширения. 1СМРу6-заголовок идентифицируется значением «58» в поле «Следующий заголовок» заголовка, который непосредственно предшествует 1СМРу6-заголовку. (Примечание. Это значение отличает­ ся от того, которое используется в стандарте ICMPv4.) На рис. 12.24 представлен общий формат 1СМРу6-сообщений.

Рис. 12.24. Общий формат 1СМРу6-сообщений

Поле «Тип 1СМРу6-сообщения» указывает на тип ICMPv6-co- общения. Значение, содержащееся в этом поле, определяет формат следующих за этим полем данных.

Поле «Тип кодирования» зависит от типа 1СМРу6-сообщения. Оно предназначено для создания дополнительного уровня структу­ ры сообщения.

Поле «Проверочная сумма» используется для обнаружения ис­ каженных данных в 1СМРу6-сообщении и некоторых частях 1Ру6-за- головка.

Определение адреса источника сообщения. IP-узел, который передает 1СМРу6-сообщение, должен определить 1Ру6-адреса ис­ точника и получателя сообщения и разместить их в 1Ру6-заголовке и только потом рассчитать контрольную сумму. Если IP-узел имеет более одного адреса, то тогда он должен выбрать адрес источника сообщения следующим образом:

оесли сообщение является ответом на сообщение, которое было принято этим IP-узлом и содержало один из его уникальных ад­ ресов, то тогда адрес источника в ответе должен быть таким, ко­ торый был указан в принятом сообщении (адрес получателя);

оесли сообщение является ответом на сообщение, которое было принято этим IP-узлом и содержало широковещательный или групповой адрес (причем данный IP-узел входит в это объеди­ нение узлов с таким адресом), то тогда адрес источника в отве­ те должен быть уникальным адресом того интерфейса, на ко­ торый поступил IP-пакет с широковещательным или группо­ вым адресом;

весли сообщение является ответом на сообщение, переданное по адресу, который не принадлежит данному IP-узлу (но было им получено), то тогда целесообразно, чтобы адрес источника был уникальным адресом этого IP-узла, который используется по­ следним для диагностирования ошибок (то есть, наиболее при­ емлем для диагностирования ошибок). Например, если сообще­ ние является ответом на IP-пакет, подлежащий дальнейшей ретрансляции, но которая не может быть успешно осуществлена, то тогда адрес источника в ответе должен быть уникальным ад­