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

1Ру6-заголовка. Его наличие указывается нулевым значением в поле «Следующий заголовок» 1Ру6-заголовка.

Если в результате обработки заголовка 1Ру6-пакета IP-узлу по­ требуется обратиться к следующему заголовку, но значение в поле «Следующий заголовок» текущего заголовка IP-узлом не выявлено, то тогда последний должен уничтожить 1Ру6-пакет и передать ICMP-сообщение «Параметрическая проблема» («Parameter Problem») IP-узлу отправителю 1Ру6-пакета. Это ICMP-сообщение должно содер­ жать значение «1» в поле «Код ошибки» («Обнаружен неопределён­ ный тип поля «Следующий заголовок»), а в поле «Указатель» («Pointer») должна присутствовать «копия» неустановленного значе­ ния из поля «Следующий заголовок» принятого 1Ру6-пакета. Анало­ гичные действия должны быть предприняты в случае, если IP-узел об­ наружил нулевое значение в поле «Следующий заголовок» в составе какого-либо заголовка, не являющегося 1Ру6-заголовком.

Каждый заголовок расширения имеет длину, кратную 8 окте­ там. Поля, состоящие из нескольких октетов в рамках заголовка расширения, устанавливаются в своих естественных границах.

Полная (с точки зрения функциональной совместимости) про­ граммная реализация 1Ру6-протокола включает следующие заголов­ ки расширения:

•«Нор-Ьу-Нор Options» - «Дополнительные функции: ретранс­ ляция»;

в«Routing» (Туре 0) - «Маршрутизация»;

о«Fragment» - «Фрагментация»;

в«Destination Options» - «Дополнительные функции: узел-полу­ чатель»;

о«Authentication» - «Аутентификация» (определен в стандарте RFC-4302);

о«Encapsulating Security Payload» - «Повторное обрамление по­ ля полезной нагрузки с целью её защиты» (определён в стан­ дарте RFC-4303).

Порядок следования заголовков расширения. Когда в одном

итом же 1Ру6-пакете используется более чем один заголовок расши­ рения, то тогда рекомендуется, чтобы эти заголовки следовали в следующем порядке:

о«1Ру6-заголовок»;

о«Нор-Ьу-Нор Options»;

о«Destination Options» (Примечание. Этот заголовок содержит дополнительные функции, которые предназначены для пер­ вого получателя, адрес которого указан в поле «Адрес получа­ теля пакета», и всех последующих получателей, указанных в заголовках «Маршрутизация».);

о«Routing»;

о«Fragment»;

о«Authentication» (Примечание. Дополнительные рекомендации по использованию этого заголовка представлены в стандартах RFC-4302 и RFC-4303.);

о«Encapsulating Security Payload» (.Примечание. Дополнитель­ ные рекомендации по использованию этого заголовка пред­ ставлены в стандартах RFC-4302 и RFC-4303.);

о«Destination Options» (Примечание. Этот заголовок содержит дополнительные функции, которые предназначены для по­ следнего получателя этого пакета.);

о«Upper-layer header» - «Заголовок выше лежащего уровня». Каждый заголовок расширения должен присутствовать не бо­

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

Если «Заголовок вышележащего уровня» является другим 1Ру6-заголовком (в случае туннелирования IP-трафика), то за ним могут следовать его собственные заголовки расширения, которые располагаются в таком же порядке, как было указано выше.

Если определен (или когда будет определен) другой (новый) за­ головок расширения, то должен быть определен порядок его следова­ ния относительно представленных выше заголовков расширения.

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

Дополнительные функции. Только два заголовка расшире­ ния определяют дополнительные функции, а именно «Дополни­ тельные функции: ретрансляция» («Нор-Ьу-Нор Options») и «До­ полнительные функции: узел-получатель» («Destination Options»). Каждый из них включает три поля (рис. 12.13):

о«Тип дополнительной функции» («Option Туре») - 8-битовое беззнаковое целое число, которое представляет идентифика­ тор, определяющий тип дополнительной функции;

о«Длина поля «Данные дополнительной функции» («Opt Data Len») - 8-битовое беззнаковое целое число, которое определяет длину поля «Данные дополнительной функции» в октетах;

•«Данные дополнительной функции» («Option Data») - поле переменной длины, содержащее специфические данные до­ полнительной функции.

Последовательность дополнительный функций в рамках заго­ ловка должна обрабатываться строго в том порядке, как они следу­ ют в заголовке. Приёмный модуль не должен, например, сканиро­ вать весь заголовок в поисках соответствующего типа дополнитель­ ной функции и реализовывать найденный функцию прежде всех остальных функций.

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

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

в«00» - пропустить эту функцию и продолжить обработку заго­ ловка;

• «01» - уничтожить пакет;

©«10» - уничтожить пакет и, не обращая внимания на поле «Адрес получателя пакета» с точки зрения, содержит оно групповой 1Ру6-адрес или нет, передать отправителю этого пакета ICMP-сообщение, содержащее значение «2» в поле «Код ошибки» («Обнаружен неопределённый тип дополнительной функции»);

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

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

о«0» - данные дополнительной функции не будут изменяться во время доставки 1Ру6-пакета;

о «1» - данные дополнительной функции могут изменяться во время доставки 1Ру6-пакета.

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

Третий старший бит является элементом типа дополнитель­ ной функции, но независящим от типа функции. То есть, соответст­ вующая дополнительная функция определяется всеми 8-ью битами поля «Тип дополнительной функции», но только 5 битов младшего порядка определяют конкретный тип этой функции.

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

Одиночные дополнительные функции могут иметь специфи­ ческие требования к структуре своего формата, чтобы гарантиро­ ванного обеспечить совпадение параметров, состоящих из несколь­ ких октетов с естественными границами в рамках полей «Данные дополнительной функции». Это требование заключается в выпол­ нении соотношения: «xn+у». Оно означает, что длина поля «Тип дополнительной функции» должна равняться целому числу, со­ стоящему из «х» октетов от начала заголовка и плюс «у» октетов. Например, «2п» означает любой сдвиг на два октета от начала заго­ ловка, а «8п+2» - любой сдвиг на восемь октетов от начала заголовка плюс два октета.

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

аименно:

•первый тип дополнения («РасИ») - требования к структуре формата отсутствуют (рис. 12.14). (.Примечание. Формат такого типа дополнения является специальным случаем, то есть он не имеет полей для указания длины и значения параметра.) Этот тип функции используется для вставки только одного октета в качестве дополнения последовательности заголовка, описы­

вающей дополнительную функцию. Если же необходимо ис­ пользовать несколько октетов дополнения последовательно­ сти, то тогда целесообразно использовать второй тип функции дополнения «PadN», а не несколько раз первый тип «Padl»;

Рис. 12.15. Формат второго типа дополнения

©второй тип дополнения («PadN») - требования к структуре формата отсутствуют (рис. 12.15). Этот тип функции использу­ ется для вставки двух или более октетов в качестве дополнения последовательности заголовка, описывающей дополнительную функцию. Для дополнения из «N» октетов, поле «Длина поля «Данные дополнительной функции» будет содержать значе­ ние «N-2», а само поле «Данные дополнительной функции» будет иметь длину «N-2» нулевых октетов.

Заголовок расширения «Дополнительные функции: ретранс­ ляция». Заголовок «Дополнительные функции: ретрансляция» («Нор-Ьу-Нор Options») используется для доставки дополнительной информации, которая должна обязательно просматриваться каж­ дым 1Ру6-узлом, расположенном на маршруте доставки 1Ру6-пакета. Данный заголовок расширения идентифицируется полем «Сле­ дующий заголовок» (в 1Ру6-заголовке), содержащим нулевое значе­ ние. На рис. 12.16 представлен формат этого заголовка, который включает следующие поля:

I_______________________________________I

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

ретрансляция»

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

о«Число оставшихся ретрансляционных участков» («Segments Left») - 8-битовое беззнаковое целое число, определяющее ко­ личество оставшихся ретрансляционных участков, то есть точ­ ное число перечисленных промежуточных IP-узлов, которое должен «посетить» данный 1Ру6-пакет, прежде чем он достиг­ нет конечного узла-получателя;

о«Специфические данные маршрутизации» («Type-specific data») - поле переменной длины, формат которого определя­ ется полем «Тип маршрутизации», а его длина такова, что весь заголовок «Маршрутизация» включает целое число 8-октетных последовательностей.

Рис. 12.18. Формат заголовка расширения «Маршрутизация»

(для типа маршрутизации «О»)

Если в процессе обработки принятого 1Ру6-пакета IP-узел об­ наружит заголовок расширения «Маршрутизация» с «непонятным» значением в поле «Тип маршрутизации», то тогда последующие действия узла зависят от значения в поле «Число оставшихся ретрансляционных участков», а именно:

•если поле «Число оставшихся ретрансляционных участков» содержит нулевое значение, то тогда IP-узел должен игнори­ ровать заголовок расширения «Маршрутизация» и продол­ жить обрабатывать следующий заголовок 1Ру6-пакета, тип ко­ торого определен в поле «Идентификатор следующего заго­ ловка расширения» заголовка «Маршрутизация»;

весли поле «Число оставшихся ретрансляционных участков» содержит не нулевое значение, то тогда IP-узел должен унич­ тожить 1Ру6-пакет и передать ICMP-сообщение «Параметриче-

ская проблема» («Parameter Problem») IP-узлу отправителю 1Ру6-пакета. Это ICMP-сообщение должно содержать значение «О» в поле «Код ошибки», которое указывает на неизвестный тип маршрутизации.

Если после обработки заголовка «Маршрутизация» в приня­ том 1Ру6-пакете промежуточный IP-узел обнаружит, что этот пакет должен быть передан в линию связи, допускающей доставку паке­ тов меньшей длины, чем длина данного ретранслируемого пакета, то тогда IP-узел должен уничтожить 1Ру6-пакет и передать ICMPсообщение «Слишком большая длина пакета» («Packet Too Big») IPузлу отправителю ГРуб-пакета. На рис. 12.18 представлен формат заголовка расширения «Маршрутизация» (для типа маршрутиза­ ции «О»), в котором:

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

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

о«Тип маршрутизации» («Routing Туре») - 8-битовый опреде­ литель, равный «О»;

о«Число оставшихся ретрансляционных участков» («Segments Left») - 8-битовое беззнаковое целое число, определяющее ко­ личество оставшихся ретрансляционных участков, то есть точ­ ное число перечисленных промежуточных IP-узлов, которое должен ещё «посетить» данный 1Ру6-пакет, прежде чем он дос­ тигнет конечного узла-получателя;

о«Зарезервировано» («Reserved») - 32-битовое зарезервирован­ ное поле, которое заполняется нулями при передаче и игно­ рируется при получении 1Ру6-пакета;

®«Адреса [1.. .п]» - последовательность пронумерованных (1.. .п)

128-битовых адресов.

Групповые 1Ру6-адреса никогда не должны присутствовать в заголовке «Маршрутизация», если поле «Тип маршрутизации» со­ держит нулевое значение, или в поле «Адрес получателя пакета» 1Ру6-заголовка, если в пакете имеет место заголовок «Маршрутиза­ ция» с нулевым полем «Тип маршрутизации».

Заголовок «Маршрутизация» не поверяется и не обрабатывается до тех пор, пока 1Ру6-пакет не поступит на конечный IP-узел, адрес ко­ торого указан в поле «Адрес получателя пакета» 1Ру6-заголовка. В этом IP-узле происходит поверка поля «Идентификатор следующего за­ головка расширения» в заголовке расширения, непосредственно предшествующем заголовку «Маршрутизация».

Заголовок расширения «Фрагментация». Заголовок расши­ рения «Фрагментация» используется 1Ру6-узлом/отправителем для передачи 1Ру6-пакета, длина которого превышает максимально до­ пустимый размер передаваемой единицы данных для конкретного маршрута доставки (path MTU) до конечного 1Ру6-узла/получателя. (.Примечание. В отличие 1Ру4-протокола, 1Ру6-протокол допускает процедуру фрагментации только в 1Ру6-узлах/ отправителях, но не в маршрутизаторах, расположенных на маршруте доставки пакета.) Заголовок «Фрагментация» идентифицируется в поле «Следующий заголовок» значением «44» заголовка расширения, который непо­ средственно предшествует заголовку «Фрагментация». На рис. 12.19 представлен формат заголовка расширения «Фрагментация», кото­ рый содержит следующие поля:

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

в«Зарезервировано» («Reserved») - 8-битовое зарезервирован­ ное поле, которое при передаче заполняется нулями, а при приёме игнорируется;

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

««Зарезервировано» («Reserved») - 2-битовое зарезервирован­ ное поле, которое при передаче заполняется нулями, а при приёме игнорируется;

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

о«Идентификация» («Identification») - 32-битовое поле (будет рассмотрено ниже).

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

«Идентификатор

«Смещение (сдвиг)

следующего Зарезервировано Зарезервировано «Флаг» данного фрагмента»

заголовка»

Идентификация

Рис. 12.19. Формат заголовка расширения «Фрагментация»

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

Исходный, большой и не расфрагментированный пакет назы­ вается «оригинальным пакетом». Считается, что он состоит из двух частей (рис. 12.20).

Часть пакета, не подлежащая

Часть пакета, подлежащая фрагментации

фрагментации

Рис. 12.20. Формат «оригинального пакета»

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