Оглавление
- 1. Предисловие
- 2. Терминология
- 3. Формат заголовка IPv6-пакета
- 4. Заголовки расширения в IPv6-пакете
- 4.1. Порядок следования заголовков расширения
- 4.2. Дополнительные функции
- 4.3. Заголовок расширения «Дополнительные функции: ретрансляция»
- 4.4. Заголовок расширения «Маршрутизация»
- 4.5. Заголовок расширения «Фрагментация»
- 4.6. Заголовок расширения «Дополнительные функции: узел-получатель»
- 4.7. Отсутствие следующего заголовка расширения
- 5. Проблемы, связанные с выбором длины IPv6-пакета
- 6. Маркеры потоков
- 7. Классы трафика
- 8. Проблемы протоколов верхних уровней
- 8.1. Проверочная сумма протоколов транспортного уровня
- 8.2. Максимальное «время жизни» IPv6-пакета
- 8.3. Максимальный размер поля полезной нагрузки в сообщении протокола верхнего уровня
- 8.4. Ответная реакция на принятые пакеты, содержащие заголовки расширения «Маршрутизация»
- Приложение A. Семантика и использование поля «Маркер потока»
- Приложение B. Правила форматирования для дополнительных функций
- Ссылки
1. Предисловие
Этот стандарт определяет шестую версию протокола сетевого уровня в Internet (IP-протокол), являясь преемником четвертой версии IP-протокола (IPv4-адресация). Эти версии IP-протокола отличаются в следующих категориях:
Расширение адресного пространства.
IPv6-протокол увеличивает размер IP-адреса с 32 до 128 битов с целью обеспечения нескольких уровней иерархии в пространстве адресов, увеличения числа IP-узлов, которым может быть присвоен IP-адрес, и упрощения автоматической настройки адресов. Значительно возрастает масштабируемость групповой маршрутизации, за счёт включения специализированного поля «Диапазон» в групповые IPv6-адреса. А также введён новый тип адресов, именуемый «альтернативным», который используется для доставки пакетов в одну из любых групп IP-узлов.
Упрощение формата заголовка.
Некоторые поля заголовка IPv4-пакета были поделены или стали дополнительными с целью снижения общих затрат на обработку пакета и для ограничения затрат, связанных с используемой шириной полосы пропускания, необходимой для доставки заголовка IPv6-пакета.
Значительное улучшение поддержки функций расширения и иных дополнительных функций.
Изменения в способе кодирования дополнительных функций в заголовке IPv6-пакета позволили увеличить эффективность доставки, устранить предельные границы на размер полей для дополнительных функций и существенно повысить гибкость при введении новых дополнительных функций в дальнейшем.
Функция маркирования потока IPv6-пакетов.
Эта новая функция была введена с целью маркирования пакетов, принадлежащих соответствующим «потокам» трафика, по отношению к которым передающая сторона требует специализированной обработки, например, обеспечение качества обслуживания в режиме «не по-умолчанию» («non-default quality of service») или обслуживание в масштабе реального времени («real-time»);
Функции аутентификации и обеспечения безопасности.
Для IPv6-пакетов стандартизированы функции аутентификации, обеспечения целостности и конфиденциальности данных.
Данный стандарт определяет только логическую характеристику IP-протокола, то есть формат (структуру) IP-пакета и правила кодирования его внутренних полей.
2. Терминология
IP-узел (node):
Аппаратно-программный комплекс, реализующий IPv6-протокол.
Маршрутизатор (router):
IP-узел, который доставляет IPv6-пакеты, не адресованные ему самому в явном виде.
Это свойство маршрутизатора не касается специализированных IP-пакетов управления самим маршрутизатором, передаваемых в соответствии с SNMP-протоколом (Simple Network Management Protocol).
Сервер (host):
Любой IP-узел, который не является маршрутизатором.
Верхний уровень Internet-архитектуры (upper layer):
В данном случае транспортный уровень (четвёртый). Например, протоколы транспортного уровня TCP или UDP, или управляющий протокол ICMP, или протокол маршрутизации OSPF. Однако, в случае реализации функции повторного обрамления (encapsulation) пакета (в режиме туннелирования) это могут быть кадры протоколов канального уровня (в Internet-архитектуре существуют стандарты объединения различных ЛВС с помощью IP-протокола, например, протоколы IPX и AppleTalk).
Линия (канал) связи (link):
Средство связи или среда передачи, с помощью которых IP-узлы могут связываться на канальном уровне Internet-архитектуры (например, ЛВС «Ethernet», протоколы РРР, X.25, Frame Relay или ATM).
Соседние IP-узлы (neighbors):
IP-узлы, подключённые к одной и той же линии (каналу) связи.
Интерфейс (interface):
В данном случае речь идёт о сетевом (канальном) интерфейсе IP-узла, с помощью которого этот узел подключен к линии (каналу) связи.
Адрес (address):
Сетевой IPv6-идентификатор интерфейса или группы интерфейсов.
Пакет (packet):
Единица данных IPv6-протокола, которая включает заголовок и так называемое поле полезной нагрузки (поле данных).
Максимально допустимый размер передаваемой единицы данных для конкретной линии (канала) связи (link MTU, maximum transmission unit):
Максимальный размер пакета в октетах, который может быть передан по конкретной линии (каналу) связи.
Максимально допустимый размер передаваемой единицы данных для конкретного маршрута доставки (path MTU):
Линия (канал) связи с наименьшим значением MTU среди всех линий (каналов) связи, входя щих в маршрут (может состоять из нескольких ретрансляционных участков) доставки пакета между IP-узлом отправителем и IP-узлом получателем.
Замечание. Существует возможность, хотя это весьма странно, что после настройки сетевого устройства с несколькими интерфейсами оно будет, с одной стороны, транслировать не предназначенные ему IP-пакеты, которые поступили из некоторой совокупности его же интерфейсов (но не от всех), а с другой стороны, оно будет уничтожать не предназначенные ему IP-пакеты, которые поступили из других оставшихся интерфейсов. Такое устройство должно удовлетворять требованиям протокола для маршрутизаторов при получении IP-пакетов из интерфейсов, предназначенных для ретрансляции пакетов, а также при взаимодействии с соседними сетевыми устройствами через эти же интерфейсы. Такое устройство должно удовлетворять требованиям протокола для серверов при получении IP-пакетов из интерфейсов, предназначенных для уничтожения пакетов, а также при взаимодействии с соседними сетевыми устройствами через эти же интерфейсы.
3. Формат заголовка IPv6-пакета
На рис.1 представлен формат заголовка IPv6-пакета.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Версия IP-протокола | Класс трафика | Маркер потока | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Размер поля полезной нагрузки | Следующий заголовок | Число ретрансляций | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Адрес отправителя пакета + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Адрес получателя пакета + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.1. Формат заголовка IPv6-пакета
Заголовок IPv6-пакета включает следующие поля:
«Версия IP-протокола» (Version):
4-битовое поле, содержащее значение «6».
«Класс трафика» (Traffic Class):
8-битовое поле, которое указывает на класс трафика.
«Маркер потока» (Flow Label):
20-битовое поле, которое содержит маркер потока.
«Размер поля полезной нагрузки» (Payload Length):
16-битовое беззнаковое целое число, которое указывает на размер поля полезной нагрузки в октетах, следующего сразу после заголовка (включая заголовки расширения).
«Следующий заголовок» (Next Header):
8-битовый определитель, который указывает на тип заголовка, следующего сразу за эти заголовком.
«Число ретрансляций» (Hop Limit):
8-битовое беззнаковое целое число, которое указывает на максимальное число ретрансляционных участков. Это число уменьшается на единицу каждым IP-узлом, через который проследовал IPv6-пакет. Если это поле содержит нулевое значение, то тогда IPv6-пакет уничтожается.
«Адрес отправителя пакета» (Source Address):
128-битовый адрес отправителя пакета.
«Адрес получателя пакета» (Destination Address):
128-битовый адрес конечного получателя пакета, то есть которому предназначен данный пакет. (Однако, возможно это — не самый последний получатель, если в IPv6-пакете представлен заголовок маршрутизации.)
4. Заголовки расширения в IPv6-пакете
В IPv6-протоколе предусмотрена доставка дополнительной (служебной) закодированной информации сетевого уровня, которая может быть размещена в IPv6-пакете между IPv6-заголовоком и заголовком верхнего уровня. Для такой доставки существует несколько так называемых заголовков расширения, причём каждый из них идентифицируется собственным значением в поле «Следующий заголовок». На рис.2 приведены примеры нескольких заголовков расширения в IPv6-пакетах.
+-------------------------+------------------------- | IPv6-заголовок | TCP-заголовок + данные | | | «Следующий заголовок» = | | TCP | +-------------------------+------------------------- +-------------------------+-------------------------+------------------------- | IPv6-заголовок | Заголовок маршрутизации | TCP-заголовок + данные | | | | «Следующий заголовок» = | «Следующий заголовок» = | | Routing | TCP | +-------------------------+-------------------------+------------------------- +-------------------------+-------------------------+-------------------------+------------------------- | IPv6-заголовок | Заголовок маршрутизации | Заголовок фрагментации | Фрагмент | | | | TCP-заголовка + данных | «Следующий заголовок» = | «Следующий заголовок» = | «Следующий заголовок» = | | Routing | Fragment | TCP | +-------------------------+-------------------------+-------------------------+------------------------- Рис.2. Примеры заголовков расширения в IPv6-пакетах
За одним исключением, заголовки расширения не проверяются или не обрабатываются ни одним IP-узлом на протяжении всего маршрута доставки IPv6-пакета, причём до тех пор, пока последний не достигнет IP-узла (или каждого IP-узла из группы IP-узлов, в случае групповой рассылки пакета), адрес которого содержится в поле «Адрес получателя пакета» IPv6-заголовка. В данном случае при нормальном демультиплексировании поле «Следующий заголовок» IPv6-заголовка «запрашивает» специализированный модуль для обработки первого заголовка расширения или заголовка вышележащего уровня, если конечно заголовок расширения отсутствует. Содержание и семантика каждого заголовка расширения определяет необходимо или нет переходить к обработке следующего заголовка. Более того, заголовки расширения должны обрабатываться именно в том порядке, как они представлены в IPv6-пакете. Приёмный модуль никогда не должен, например, сканировать весь IPv6-пакет в поисках соответствующего типа заголовка расширения и обрабатывать найденный заголовок прежде всех остальных заголовков расширения.
Указанное выше исключение относится к заголовку «Дополнительные функции: ретрансляция» («Hop-by-Hop Options»), содержащему информацию, которая должна контролироваться и обрабатываться каждым IP-узлом, расположенном на маршруте доставки IPv6-пакета, включая IP-узлы отправителя и получателя. Если такой заголовок представлен, то он должен следовать сразу же после IPv6-заголовка. Его наличие указывается нулевым значением в поле «Следующий заголовок» IPv6-заголовка.
Если в результате обработки заголовка IPv6-пакета IP-узлу потребуется обратиться к следующему заголовку, но значение в поле «Следующий заголовок» текущего заголовка IP-узлом не выявлено, то тогда последний должен уничтожить IPv6-пакет и передать ICMP-сообщение «Параметрическая проблема» («Parameter Problem») IP-узлу отправителю IPv6-пакета. Это ICMP-сообщение должно содержать значение «1» в поле «Код ошибки» («Обнаружен неопределённый тип поля «Следующий заголовок»), а в поле «Указатель» («Pointer») должен присутствовать «копия» неустановленного значения величины из принятого IPv6-пакета. Аналогичные действия должны быть предприняты в случае, если IP-узел обнаружил нулевое значение в поле «Следующий заголовок» в составе какого-либо заголовка, не являющегося IPv6-заголовком.
Каждый заголовок расширения имеет длину, кратную 8 октетам. Поля, состоящие из нескольких октетов в рамках заголовка расширения, устанавливаются в своих естественных границах, то есть поля длиной «n» октетов размещаются в последовательности, состоящей из «n» октетов от начала заголовка, для n= 1, 2, 4 или 8.
Полная (с точки зрения функциональности) программная реализация IPv6-протокола включает следующие заголовки расширения:
«Hop-by-Hop Options»:
«Дополнительные функции: ретрансляция»;
«Routing» (Type 0):
«Маршрутизация»;
«Fragment»:
«Фрагментация»;
«Destination Options»:
«Дополнительные функции: узел-получатель»;
«Authentication»:
«Аутентификация» (определен в стандарте RFC-4302);
«Encapsulating Security Payload»:
«Повторное обрамление поля полезной нагрузки с целью её защиты» (определен в стандарте RFC-4303).
4.1. Порядок следования заголовков расширения
Когда в одном и том же IPv6-пакете используется более чем один заголовок расширения, то тогда рекомендуется, чтобы эти заголовки следовали в следующем порядке:
«IPv6-заголовок»;
«Hop-by-Hop Options»;
«Destination Options»;
Замечание. Этот заголовок содержит дополнительные функции, которые предназначены для первого получателя, адрес которого указан в поле «Адрес получателя пакета», и всех последующих получателей, указанных в заголовках «Маршрутизация».
«Routing»;
«Fragment»;
«Authentication»;
Замечание. Дополнительные рекомендации по использованию этого заголовка представлены в стандартах RFC-4302 и RFC-4303.
«Encapsulating Security Payload»;
Замечание. Дополнительные рекомендации по использованию этого заголовка представлены в стандартах RFC-4302 и RFC-4303.
«Destination Options»;
Замечание. Этот заголовок содержит дополнительные функции, которые предназначены для последнего получателя этого пакета.
«Upper-layer header»:
«Заголовок выше лежащего уровня».
Каждый заголовок расширения должен присутствовать не более одного раза, за исключением заголовка «Дополнительные функции: узел-получатель», который должен присутствовать не более двух раз (первый раз — перед заголовком «Маршрутизация», а второй раз — перед «Заголовком выше лежащего уровня»).
Если «Заголовок выше лежащего уровня» является другим IPv6-заголовком (в случае туннелирования IP-трафика), то за ним могут следовать его собственные заголовки расширения, которые располагаются в таком же порядке, как было указано выше.
Если определен (или когда будет определен) другой (новый) заголовок расширения, то тогда должен быть определен порядок его следования относительно представленных выше заголовков расширения.
IPv6-узлы обязательно должны принимать на обработку следующие в любом порядке и представленные по нескольку раз в одном и том же IPv6-пакете заголовки расширения, за исключением заголовка «Дополнительные функции: ретрансляция», который в обязательном порядке должен следовать сразу после IPv6-заголовка. И все-таки, несмотря на то, что было сказано выше, чрезвычайно важно, чтобы отправители IPv6-пакетов твёрдо придерживались представленных ранее рекомендаций до тех пор, пока не будут стандартизованы новые рекомендации.
4.2. Дополнительные функции
Только два заголовка расширения определяют дополнительные функции, а именно «Дополнительные функции: ретрансляция» («Hop-by-Hop Options») и «Дополнительные функции: узел-получатель» («Destination Options»). Каждый из них включает три поля (рис.3):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - | Тип дополнительной | Длина поля «Данные | Данные дополнительной | функции | дополнительной функции» | функции +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - Рис.3. Формат заголовков «Дополнительные функции: …»
«Тип дополнительной функции» («Option Type»):
8-битовое беззнаковое целое число, которое представляет идентификатор, определяющий тип дополнительной функции.
«Длина поля «Данные дополнительной функции» («Opt Data Len»):
8-битовое беззнаковое целое число, которое определяет длину поля «Данные дополнительной функции» в октетах.
«Данные дополнительной функции» («Option Data»):
поле переменной длины, содержащее специфические данные дополнительной функции.
Последовательность дополнительный функций в рамках заголовка должна обрабатываться строго в том порядке, как они следуют в заголовке. Приёмный модуль никогда не должен, например, сканировать весь заголовок в поисках соответствующего типа дополнительной функции и реализовывать найденный функцию прежде всех остальных функций.
Кодирование идентификаторов, определяющих тип дополнительной функции, имеет следующее правило. Два старших бита идентификатора должны выбираться таким образом, чтобы IPv6-узел «понимал» что делать дальше с принятым IPv6-пакетом, если он не определил тип функции. Эти старшие дебиты могут иметь следующие значения:
«00» — пропустить эту функцию и продолжить обработку заголовка;
«01» — уничтожить пакет;
«10» — уничтожить пакет и, не обращая внимания на поле «Адрес получателя пакета» с точки зрения, содержит оно групповой IPv6-адрес или нет, передать отправителю этого пакета ICMP-сообщение, содержащее значение «2» в поле «Код ошибки» («Обнаружен неопределённый тип дополнительной функции»);
«11» — уничтожить пакет и, если только поле «Адрес получателя пакета» не содержит групповой IPv6-адрес, передать отправителю этого пакета ICMP-сообщение, содержащее значение «2» в поле «Код ошибки» («Обнаружен неопределённый тип дополнительной функции»).
Третий старший бит идентификаторов, определяющих тип дополнительной функции, указывает на возможность изменения (будут изменяться или нет) данных этой дополнительной функции (в поле «Данные дополнительной функции») во время доставки IPv6-пакета на конечный узел-получатель. Этот бит имеет следующее кодирование:
«0» — данные дополнительной функции не будут изменяться во время доставки IPv6-пакета;
«1» — данные дополнительной функции могут изменяться во время доставки IPv6-пакета.
Если в IPv6-пакете представлен заголовок аутентификации («Authentication»), то тогда при вычислении соответствующих параметров аутентификации данные дополнительной функции (в поле «Данные дополнительной функции»), которые могут быть изменены во время доставки IPv6-пакета, должны восприниматься как полностью нулевая последовательность (последовательность из нулевых октетов).
Третий старший бит, представленный выше, воспринимается как элемент типа дополнительной функции, причем независимый от типа функции. То есть, соответствующая дополнительная функция определяется всеми 8-ью битами поля «Тип дополнительной функции», но только 5 битов младшего порядка определяют конкретный тип этой функции.
Одна и та же номерная ёмкость поля «Тип дополнительной функции» используется одновременно в двух заголовках: «Дополнительные функции: ретрансляция» и «Дополнительные функции: узел-получатель». Однако, описание (назначение) соответствующей дополнительной функции может ограничить её использование только в одном из этих двух заголовков.
Одиночные дополнительные функции могут иметь специфические требования к структуре своего формата в целях гарантированного обеспечения того, что параметры, состоящие из нескольких октетов, в рамках полей «Данные дополнительной функции» совпадут с естественными границами. Требование к структуре формата дополнительной функции заключается в использовании следующего соотношения: «xn+y». Оно означает, что поле «Тип дополнительной функции» должно быть представлено как целое число, состоящее из «х» октетов от начала заголовка и плюс «y» октетов. Например, «2n» означает любой сдвиг на два октета от начала заголовка, а «8n+2» — любой сдвиг на восемь октетов от начала заголовка плюс два октета.
Существуют два типа функции дополнения символами двоичной последовательности, которые используются тогда, когда появляется необходимость дополнения заголовка до длины, кратной 8 октетам. Эти типы дополнения должны в обязательном порядке определяться всеми программными реализациями IPv6-протокола, а именно:
Первый тип дополнения («Pad1»): требования к структуре формата отсутствуют (рис.4).
+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ Рис.4. Формат первого типа дополнения
Замечание. Формат такого типа дополнения является специальным случаем, то есть он не имеет полей для указания длины и значения параметра.
Этот тип функции используется для вставки только одного октета в качестве дополнения последовательности заголовка, описывающей дополнительную функцию. Если же необходимо использовать несколько октетов дополнения последовательности, то тогда целесообразно использовать второй тип функции дополнения «PadN», а не несколько раз первый тип «Pad1».
Второй тип дополнения («PadN»): требования к структуре формата отсутствуют (рис.5).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - | | Длина поля | | 1 | «Данные дополнительной | Данные дополнительной функции | | функции» | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - Рис.5. Формат второго типа дополнения
Этот тип функции используется для вставки двух или более октетов в качестве дополнения последовательности заголовка, описывающей дополнительную функцию. Для дополнения из «N» октетов, поле «Длина поля «Данные дополнительной функции» будет содержать значение «N-2», а само поле «Данные дополнительной функции» будет состоять из «N-2» нулевых октетов.
4.3. Заголовок расширения «Дополнительные функции: ретрансляция»
Заголовок «Дополнительные функции: ретрансляция» («Hop-by-Hop Options») используется для доставки дополнительной информации, которая должна обязательно просматриваться каждым IPv6-узлом, расположенном на маршруте доставки IPv6-пакета. Данный заголовок расширения идентифицируется полем «Следующий заголовок» (в IPv6-заголовке), содержащим нулевое значение. На рис.6 представлен формат этого заголовка, который включает следующие поля:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина поля «Данные | | | следующего заголовка» | дополнительной функции» | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + . . . Данные дополнительной функции: ретрансляция . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.6. Формат заголовка «Дополнительные функции: ретрансляция»
«Идентификатор следующего заголовка расширения» («Next Header»):
8-битовый определитель, который идентифицирует тип заголовка расширения, следующего сразу за заголовком «Дополнительные функции: ретрансляция» (используемые значения представлены в стандарте RFC-1700).
«Длина заголовка расширения «Данные дополнительной функции: ретрансляция» («Hdr Ext Len»):
8-битовое беззнаковое целое число, которое определяет длину заголовка расширения «Данные дополнительной функции: ретрансляция» в 8-октетовых единицах, не включая первых восьми октетов.
«Данные дополнительной функции: ретрансляция» («Options»):
Поле переменной длины, в котором весь заголовок «Дополнительные функции: ретрансляция» рассматривается как последовательность, состоящая из целого числа 8-октетных субпоследовательностей (формат представлен в 4.2).
4.4. Заголовок расширения «Маршрутизация»
Этот заголовок используется IP-узлом, передающим IPv6-пакет, для перечисления одного или нескольких промежуточных IP-узлов, которые должен «посетить» IPv6-пакет по маршруту своей доставки до конечного узла-получателя. Заголовок «Маршрутизация» идентифицируется в поле «Следующий заголовок» значением «43» заголовка расширения, который непосредственно предшествует заголовку «Маршрутизация». На рис.7 представлен формат заголовка расширения «Маршрутизация», который содержит следующие поля:
| 8 битов | 8 битов | 8 битов | 8 битов | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина поля | | «Число оставшихся | | следующего | «Специфические данные | «Тип маршрутизации» | ретрансляционных | | заголовка» | маршрутизации» | | участков» | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Специфические данные маршрутизации . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.7. Формат заголовка расширения «Маршрутизация»
«Идентификатор следующего заголовка расширения» («Next Header»):
8-битовый определитель, который идентифицирует тип заголовка расширения, следующего сразу за заголовком «Маршрутизация» (используемые значения представлены в стандарте RFC-1700);
«Длина поля «Данные дополнительной функции: ретрансляция» («Hdr Ext Len»):
8-битовое беззнаковое целое число, которое определяет длину заголовка «Маршрутизация» в 8-октетовых единицах, не включая первых восьми октетов;
«Тип маршрутизации» («Routing Type»):
8-битовый определитель, который идентифицирует соответствующий вариант заголовка «Маршрутизация»;
«Число оставшихся ретрансляционных участков» («Segments Left»):
8-битовое беззнаковое целое число, определяющее количество оставшихся ретрансляционных участков, то есть точное число перечисленных промежуточных IP-узлов, которое должен «посетить» данный IPv6-пакет, прежде чем он достигнет конечного узла-получателя;
«Специфические данные маршрутизации» («Type-specific data»):
поле переменной длины, формат которого определяется полем «Тип маршрутизации», а его длина такова, что весь заголовок «Маршрутизация» рассматривается как целое число 8-октетных последовательностей.
Если в процессе обработки принятого IPv6-пакета IP-узел обнаружит заголовок расширения «Маршрутизация» с «непонятным» значением в поле «Тип маршрутизации», то тогда последующие действия узла зависят от значения в поле «Число оставшихся ретрансляционных участков», а именно:
Если поле «Число оставшихся ретрансляционных участков» содержит нулевое значение, то тогда IP-узел должен игнорировать заголовок расширения «Маршрутизация» и продолжить обрабатывать следующий заголовок IPv6-пакета, тип которого определен в поле «Идентификатор следующего заголовка расширения» заголовка «Маршрутизация».
Если поле «Число оставшихся ретрансляционных участков» содержит не нулевое значение, то тогда IP-узел должен уничтожить IPv6-пакет и передать ICMP-сообщение «Параметрическая проблема» («Parameter Problem») IP-узлу отправителю IPv6-пакета. Это ICMP-сообщение должно содержать значение «0» в поле «Код ошибки», которое указывает на неизвестный тип маршрутизации.
Если после обработки заголовка «Маршрутизация» в принятом IPv6-пакете промежуточный IP-узел обнаружит, что этот пакет должен быть передан в линию связи, допускающей доставку пакетов меньшей длины, чем длина данного ретранслируемого пакета, то тогда IP-узел должен уничтожить IPv6-пакет и передать ICMP-сообщение «Слишком большая длина пакета» («Packet Too Big») IP-узлу отправителю IPv6-пакета. На рис.8 представлен формат заголовка расширения «Маршрутизация» (для типа маршрутизации «0»).
| 8 битов | 8 битов | 8 битов | 8 битов | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина поля | | «Число оставшихся | | следующего | «Специфические данные | «Тип маршрутизации» | ретрансляционных | | заголовка» | маршрутизации» | | участков» | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Адрес [1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Адрес [2] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Адрес [n] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.8. Формат заголовка расширения «Маршрутизация» (для типа маршрутизации «0»)
«Идентификатор следующего заголовка расширения» («Next Header»):
8-битовый определитель, который идентифицирует тип заголовка расширения, следующего сразу за заголовком «Маршрутизация» (используемые значения представлены в стандарте RFC-1700).
«Длина заголовка расширения «Маршрутизация» («Hdr Ext Len»):
8-битовое беззнаковое целое число, которое определяет длину заголовка «Маршрутизация» в 8-октетовых единицах, не включая первых восьми октетов. Если тип маршрутизации имеет значение «0», то тогда длина заголовка равна удвоенному количеству адресов в заголовке.
«Тип маршрутизации» («Routing Type»):
8-битовый определитель, равный «0».
«Число оставшихся ретрансляционных участков» («Segments Left»):
8-битовое беззнаковое целое число, определяющее количество оставшихся ретрансляционных участков, то есть точное число перечисленных промежуточных IP-узлов, которое должен ещё «посетить» данный IPv6-пакет, прежде чем он достигнет конечного узла-получателя.
«Зарезервировано» («Reserved»):
32-битовое зарезервированное поле, которое заполняется нулями при передаче и игнорируется при получении IPv6-пакета.
«Адреса [1…n]»:
Последовательность пронумерованных (1…n) 128-битовых адресов.
Групповые IPv6-адреса никогда не должны присутствовать в заголовке «Маршрутизация» если поле «Тип маршрутизации» содержит нулевое значение, или в поле «Адрес получателя пакета» IPv6-заголовка, если в пакете имеет место заголовок «Маршрутизация» с нулевым полем «Тип маршрутизации».
Заголовок «Маршрутизация» не поверяется и не обрабатывается до тех пор, пока IPv6-пакет не поступит на конечный IP-узел, адрес которого указан в поле «Адрес получателя пакета» IPv6-заголовка. В этом IP-узле происходит поверка поля «Идентификатор следующего заголовка расширения» в заголовке расширения, непосредственно предшествующем заголовку «Маршрутизация», и после этого происходит обращение к программному модулю обработки последнего. И если имеет место заголовок «Маршрутизация» с нулевым полем «Тип маршрутизации», то тогда программный модуль реализует следующий алгоритм обработки:
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else if Hdr Ext Len is odd {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Hdr Ext Len field, and discard the
packet
}
else {
compute n, the number of addresses in the Routing header, by
dividing Hdr Ext Len by 2
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1;
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n
if Address [i] or the IPv6 Destination Address is multicast {
discard the packet
}
else {
swap the IPv6 Destination Address and Address[i]
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
Для понимания работы представленного выше алгоритма будем полагать, что узел-отправитель S передает пакет узлу-получателю D, используя для этого заголовок «Маршрутизация», который «заставляет» пакет пройти промежуточные узлы I1, I2 и I3. Возможные значения в соответствующих полях IPv6-заголовка и заголовка «Маршрутизация» на каждом ретрансляционном участке представлены в Таблице 1.
| Ретрансляционный участок |
Значения полей IPv6-заголовка |
Значения полей заголовка «Маршрутизация» |
|---|---|---|
| S ⇒ I1 | Source Address = S Destination Address = I1 |
Hdr Ext Len = 6 Segments Left = 3 Address[1] = I2 Address[2] = I3 Address[3] = D |
| I1 ⇒ I2 | Source Address = S Destination Address = I2 |
Hdr Ext Len = 6 Segments Left = 2 Address[1] = I1 Address[2] = I3 Address[3] = D |
| I2 ⇒ I3 | Source Address = S Destination Address = I3 |
Hdr Ext Len = 6 Segments Left = 1 Address[1] = I1 Address[2] = I2 Address[3] = D |
| I3 ⇒ D | Source Address = S Destination Address = D |
Hdr Ext Len = 6 Segments Left = 0 Address[1] = I1 Address[2] = I2 Address[3] = I3 |
| Таблица 1 | ||
4.5. Заголовок расширения «Фрагментация»
Заголовок расширения «Фрагментация» используется IPv6-узлом/отправителем для передачи IPv6-пакета, длина которого превышает максимально допустимый размер передаваемой единицы данных для конкретного маршрута доставки (path MTU) до конечного IPv6-узла/получателя.
Замечание. В отличие IPv4-протокола, IPv6-протокол допускает процедуру фрагментации только в IPv6-узлах/отправителях, но не в маршрутизаторах, расположенных на маршруте доставки пакета.
Заголовок «Фрагментация» идентифицируется в поле «Следующий заголовок» значением «44» заголовка расширения, который непосредственно предшествует заголовку «Фрагментация». На рис.9 представлен формат заголовка расширения «Фрагментация», который содержит следующие поля:
| 8 битов | 8 битов | 13 битов | 1 бит | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | | «Смещение (сдвиг) | | | следующего | Зарезервировано | данного фрагмента» | «Флаг» | | заголовка» | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Идентификация + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.9. Формат заголовка расширения «Фрагментация»
«Идентификатор следующего заголовка расширения» («Next Header»):
8-битовый определитель, который идентифицирует начальный тип заголовка фрагментируемой части оригинального пакета (рассматривается ниже). Используемые в этом поле значения аналогичны тем, которые используются в IPv4-протоколе.
«Зарезервировано» («Reserved»):
8-битовое зарезервированное поле, которое при передаче заполняется нулями, а при приёме игнорируется.
«Смещение (сдвиг) данного фрагмента» («Fragment Offset»):
13-битовое беззнаковое целое число, которое указывает на длину (в 8-октетовых единицах) между началом фрагментируемой части исходного IPv6-пакета и началом данного фрагмента пакета (длина сдвига, см.рис.11).
«Зарезервировано» («Reserved»):
2-битовое зарезервированное поле, которое при передаче заполняется нулями, а при приёме игнорируется.
«Флаг» («M flag»):
Если равен «1» — это означает, что в дальнейшем ещё будут следовать фрагменты пакета, а если равен «0» — это означает, что данный фрагмент является последним.
«Идентификация» («Identification»):
32-битовое поле (будет рассмотрено ниже).
Для передачи IPv6-пакета, длина которого значительно превышает максимально допустимый размер передаваемой единицы данных для конкретного маршрута доставки до конечного IPv6-узла/получателя, IPv6-узел/отправитель может разделить исходный IPv6-пакет на фрагменты и передать каждый фрагмент отдельно, как самостоятельный IPv6-пакет, при этом на конечном IPv6-узел/получателе эти фрагменты будут собраны.
Для каждого IPv6-пакета, который должен быть фрагментирован, IPv6-узел/отправитель генерирует значение идентификатора. Этот идентификатор должен быть отличным от идентификатора любого другого фрагментируемого IPv6-пакета переданного совсем "недавно" и содержащего такие же «Адреса получателя/отправителя пакета». Если в пакете представлен заголовок расширения «Маршрутизация», то тогда адрес получателя пакета является адресом конечным IPv6-узла/получателя.
Термин «недавно» в данном случае означает, интервал времен в пределах максимального «времени жизни» пакета, включая время его доставки от источника к получателю, а также время, затраченное на ожидание сборки с другими фрагментами одного и того же пакета. Однако не требуется, чтобы узел/отправитель знал максимальное «времени жизни» пакета. Скорее это означает, что такое требование может быть выполнено с помощью идентификационного признака, например, значения 32-битового полно-оборотного счётчика, которое возрастает на единицу при каждом появлении пакета, подлежащего фрагментации. Выбор всегда остаётся за прикладным программным IPv6-модулем, то есть он может иметь либо один счётчик на узел или несколько счётчиков, например, один для каждого из возможных адресов узла/отправителя пакетов, или один для каждой активной адресной пары (адреса отправителя/получателя пакета).
Исходный, большой и не расфрагментированный пакет называется «оригинальным пакетом» и предполагается, что он состоит из двух частей (рис.10).
+------------------+----------------------//-----------------------+ | Часть пакета, | | | не подлежащая | Часть пакета, подлежащая фрагментации | | фрагментации | | +------------------+----------------------//-----------------------+ Рис.10. Формат «оригинального пакета»
Нефрагментируемая часть включает IPv6-заголовок и любые другие заголовки расширения, которые должны обрабатываться IPv6-узлами, расположенными на маршруте следования до конечного узла/получателя, то есть все перечисленные выше заголовки, включая также заголовок расширения «Маршрутизация», если он представлен, либо заголовок «Дополнительные функции: ретрансляция», если он представлен, либо отсутствие каких-либо заголовков расширения. Фрагментируемая часть включает оставшуюся последовательность IPv6-пакета, то есть любые заголовки расширения, которые должны обрабатываться только конечным IPv6-узлом/получателем, заголовок вышележащего уровня Internet-архитектуры и транслируемые данные.
Фрагментируемая часть оригинального IPv6-пакета разбивается на фрагменты, каждый из которых имеет длину, равную целому числу 8-октетных последовательностей, за исключением, может быть, последнего фрагмента («крайний правый»). Фрагменты передаются последовательно друг за другом с помощью фрагментальных IPv6-пакет (рис.11).
«n» фрагментов
________________________/\_________________________
/ \
Δ0
Δ1
Δ2
Δn-1
+------------------+--------------+--------------+--//--+--------------+
| Часть пакета, | Первый | Второй | | Последний |
| не подлежащая | фрагмент | фрагмент | | фрагмент |
| фрагментации | | | | |
+------------------+--------------+--------------+--//--+--------------+
+------------------+--------------------+--------------------+
| Часть пакета, | Заголовок | |
| не подлежащая | расширения | Первый фрагмент |
| фрагментации | «Фрагментация» | |
+------------------+--------------------+--------------------+
+------------------+--------------------+--------------------+
| Часть пакета, | Заголовок | |
| не подлежащая | расширения | Второй фрагмент |
| фрагментации | «Фрагментация» | |
+------------------+--------------------+--------------------+
o
o
o
+------------------+--------------------+--------------------+
| Часть пакета, | Заголовок | |
| не подлежащая | расширения | Последний фрагмент |
| фрагментации | «Фрагментация» | |
+------------------+--------------------+--------------------+
Рис.11. Формат «оригинального пакета», разделенного на фрагменты, и фрагментальные пакеты
Каждый фрагментальный пакет состоит из:
Нефрагментируемой части оригинального IPv6-пакета с полем «Размер поля полезной нагрузки» из оригинального IPv6-заголовка, в котором отбрасывается значение поля полезной нагрузки из оригинального заголовка и включается размер поля полезной нагрузки только данного фрагментального пакета. Кроме этого, значение в поле «Идентификатор следующего заголовка расширения» последнего заголовка расширения из нефрагментируемой части оригинального IPv6-пакета заменяется значением «44».
Заголовка расширения «Фрагментация», включающего:
Поле «Идентификатор следующего заголовка расширения», значение в котором указывает на первый заголовок фрагментируемой части оригинального IPv6-пакета.
Поле «Смещение (сдвиг) данного фрагмента» («Fragment Offset») — длина (в 8-октетовых единицах) между началом фрагментируемой части исходного IPv6-пакета и началом данного фрагмента пакета (длина сдвига — Δk , где к = 0…n-1). Если имеет место первый фрагмент («крайний левый»), то данное поле заполняется нулями (см. рис.11).
Поле «Флаг» («M flag»), содержащее значение «0», если данный фрагмент является последним («крайний правый»), или «1»— в противном случае.
Поле «Идентификация», содержащее идентификатор для данного оригинального IPv6-пакета.
И собственно самого фрагмента оригинального IPv6-пакета.
Размеры фрагментов должны выбираться таким образом, чтобы размеры сформированных фрагментальных пакетов не превышали максимально допустимый размер передаваемой единицы данных для конкретного маршрута доставки до конечного IPv6-узла/получателя. В IPv6-узле/получателе осуществляется обработка принятых фрагментальных пакетов и на их основе сборка оригинального пакета в нефрагментарном (исходном) формате (рис.10).
Существуют следующие правила сборки оригинального пакета:
Расфрагментированный пакет восстанавливается только из фрагментальных пакетов, которые содержат одинаковые адреса отправителя/получателя и значение идентификатора.
Нефрагментируемая часть восстановленного (ранее расфрагментированного) пакета состоит из всех перечисленных прежде заголовков, не включая заголовка фрагментации первого фрагментального пакета (то есть пакета, в котором поле «Смещение (сдвиг) данного фрагмента» содержит нулевое значение), с двумя следующими изменениями:
Значение поля «Идентификатор следующего заголовка расширения» в последнем заголовке нефрагментируемой части пакета извлекается из поля «Идентификатор следующего заголовка расширения» заголовка «Фрагментация» первого фрагментального пакета.
Значение поля «Размер поля полезной нагрузки» рассчитывается на основе длины нефрагментируемой части пакета и значения длины и значения в поле «Смещение (сдвиг) данного фрагмента» последнего фрагментального пакета. Для примера, может быть использована следующая формула для расчета значение поля «Размер поля полезной нагрузки» восстановленного пакета:
PL.orig = PL.first - FL.first - 8 + (8 × FO.last) + FL.last
где, «PL.orig» — значение в поле «Размер поля полезной нагрузки» ранее расфрагментированного (оригинального) пакета, «PL.first» — значение в поле «Размер поля полезной нагрузки» первого фрагментального пакета, «FL.first» — длина фрагмента, следующего сразу после заголовка «Фрагментация» первого фрагментального пакета, «FO.last» — значение в поле «Смещение (сдвиг) данного фрагмента» заголовка «Фрагментация» последнего фрагментального пакета, «FL.last»— длина фрагмента, следующего сразу после заголовка «Фрагментация» последнего фрагментального пакета;
Фрагментируемая часть восстанавливаемого IPv6-пакета формируется из фрагментов следующих сразу за заголовками «Фрагментация» каждого фрагментального пакета. Размер каждого фрагмента рассчитывается путём вычитания из значения в поле «Размер поля полезной нагрузки» пакета длины заголовков между IPv6-заголовком и собственно самим фрагментом. Относительная позиция каждого фрагмента определяется по значению в поле «Смещение (сдвиг) данного фрагмента».
Заголовок «Фрагментация» из восстановленного пакета изымается.
В процессе восстановления расфрагментированного пакета могут возникнуть следующие нештатные ситуации:
Если после получения первого фрагментального пакета в течение последующих 60 секунд были приняты ошибочные (неопределяемые) фрагментальные пакеты, подлежащие сборке (совместно с этим первым принятым фрагментальным пакетом), то тогда сборка данного должна быть прервана, а все принятые фрагменты для сборки этого оригинального пакета должны быть уничтожены. Если в такой ситуации был принят первый фрагментальный пакет (то есть тот пакет, в котором поле «Смещение (сдвиг) данного фрагмента» нулевое), то тогда целесообразно передать отправителю этого фрагментального пакета ICMP-сообщение «Время на сборку расфрагментированного пакета просрочено».
Если длина фрагмента, указанная в поле «Размер поля полезной нагрузки» фрагментального пакета не кратна 8 октетам и поле «Флаг» содержит единицу, то тогда этот фрагмент должен быть уничтожен, а его отправителю необходимо передать ICMP-сообщение «Параметрическая проблема» («Parameter Problem») IP-узлу отправителю IPv6-пакета. Это ICMP-сообщение должно содержать значение «0» в поле «Код ошибки», указывая тем самым на наличие ошибки в поле «Размер поля полезной нагрузки».
Если длина и смещение фрагмента таковы, что поле полезной нагрузки восстановленного пакета с помощью этого фрагмента превышает 65535 октетов, то тогда этот фрагмент должен быть уничтожен, а его отправителю необходимо передать ICMP-сообщение «Параметрическая проблема» («Parameter Problem») IP-узлу отправителю IPv6-пакета. Это ICMP-сообщение должно содержать значение «0» в поле «Код ошибки», указывая тем самым на наличие ошибки в поле «Смещение (сдвиг) данного фрагмента».
Далее приводятся не штатные ситуации, вероятность появления которых считается близкой к нулю, но они не считаются ошибками, если они всё-таки возникают:
Количество и содержание заголовков, предшествующих заголовку «Фрагментация», в различных фрагментальных пакетах, но принадлежащих одному и тому же исходному пакету, могут быть различными. Если какие бы то ни было заголовки, предшествующие заголовку «Фрагментация», были представлены в каждом фрагментальном пакете, то по прибытии в IP-узел они обрабатываются в порядке поступления фрагментов на сборку исходного пакета. И только те заголовки, которые имели место в фрагментальном пакете с нулевым полем «Смещение (сдвиг) данного фрагмента» будут размещены в восстановленном пакете.
Значения в полях «Идентификатор следующего заголовка расширения» в заголовках «Фрагментация» разных фрагментальных пакетов, но принадлежащих одному и тому же исходному пакету, могут быть различными. И только то значение поля «Идентификатор следующего заголовка расширения» будет размещено в восстановленном пакете, которое присутствовало в фрагментальном пакете с нулевым полем «Смещение (сдвиг) данного фрагмента».
4.6. Заголовок расширения «Дополнительные функции: узел-получатель»
Данный заголовок используется для доставки дополнительной информации, которая должна контролироваться только IP-узлом/получателем IPv6-пакета. Заголовок расширения «Дополнительные функции: узел-получатель» идентифицируется значением «60» в поле «Идентификатор следующего заголовка расширения» заголовка расширения, непосредственно предшествующего ему. Формат заголовка расширения «Дополнительные функции: узел-получатель» представлен на рис.12. и включает следующие поля:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина поля «Данные | | | следующего заголовка» | дополнительной функции» | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . Данные дополнительной функции: узел-получатель . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.12. Формат заголовка «Дополнительные функции: узел-получатель»
«Идентификатор следующего заголовка расширения» («Next Header»):
8-битовый определитель, который идентифицирует тип заголовка расширения, следующего сразу за заголовком «Дополнительные функции: узел-получатель» (используемые значения представлены в стандарте RFC-1700).
«Длина заголовка расширения «Данные дополнительной функции: узел-получатель» («Hdr Ext Len»):
8-битовое беззнаковое целое число, которое определяет длину заголовка расширения «Данные дополнительной функции: узел-получатель» в 8-октетовых единицах, не включая первых восьми октетов.
«Данные дополнительной функции: узел-получатель» («Options»):
Поле переменной длины, в котором весь заголовок «Дополнительные функции: узел-получатель» рассматривается как последовательность, состоящая из целого числа 8-октетных субпоследовательностей (формат представлен в 4.2).
Только в заголовке «Данные дополнительной функции: узел-получатель», представленном в этом стандарте, может использоваться функция дополнения нулями двух типов «Pad1» и «PadN», описанные в 4.2.
Замечание. Существуют только два способа указания типа кодирования информации в заголовках «Данные дополнительной функции: узел-получатель» IPv6-пакетов: либо как специальная функция, указанная в самом заголовке расширения, либо использовать отдельный заголовок расширения. Заголовки «Фрагментация» и «Аутентификация» являются конкретными примерами такого подхода. Какой именно способ можно использовать зависит от процедуры, выбранной самим узлом/получателем, который «не понимает» дополнительные данные о типе кодирования:
Если наиболее приемлемой для узла/получателя процедурой является уничтожение пакета и, если только IPv6-адрес не является групповым адресом, передача ICMP-сообщения с кодом «Неопознанный тип» узлу/отправителю, то тогда информация может быть закодирована, либо с помощью отдельного заголовка, либо с помощью специальной функции, указанной в заголовке «Данные дополнительной функции: узел-получатель», причем в поле «Тип дополнительной функции» этого заголовка будет содержаться значение «11» (две единицы в старших разрядах). Выбор также может зависеть от следующих факторов: использование наименьшего числа октетов, или обеспечение более точной синхронизации, или обеспечение наилучшего синтаксиса.
Если наиболее приемлемой является любая другая процедура, то тогда информация должна быть закодирована с помощью специальной функции, указанной в заголовке «Данные дополнительной функции: узел-получатель», причем в поле «Тип дополнительной функции» этого заголовка будет содержаться одно из значений «00», «01» или «10» (два символа в старших разрядах), выбор которого зависит выбранной процедуры. См. 4.2.
4.7. Отсутствие следующего заголовка расширения
Значение «59» в поле «Идентификатор следующего заголовка» IPv6-заголовка или любого другого заголовка расширения указывает на то, что за этим заголовком ничего не следует (данный заголовок последний в этом пакете). Если значение в поле « Размер поля полезной нагрузки» IPv6-заголовка указывает на наличие финальных октетов после заголовка расширения, содержащего значение «59» в поле «Идентификатор следующего заголовка», то тогда эти финальные октеты должны игнорироваться и передаваться без изменений, если IPv6-пакет подлежит дальнейшей ретрансляции.
5. Проблемы, связанные с выбором длины IPv6-пакета
IPv6-протокол требует, чтобы каждый Internet-канал MTU-параметр, равный 1280 октетам или больше. Если какая-либо линия связи не способна передавать 1280-октетные IPv6-пакеты целиком, то тогда должен быть специальный протокол канального уровня (в Internet-архитектуре), который бы выполнял функции фрагментирования и сборки IPv6-пакетов.
Линии связи, в которых предусмотрена настройка MTU-параметра (например, РРР-протокол канального уровня, RFC-1661), должны устанавливать значение этого параметра, равное, по крайней мере, 1280 октетов. Тем не менее, существует рекомендация, чтобы значение MTU-параметра было равно 1500 октетов или больше с целью реализации функции повторного обрамления пакета (туннелирование) без использования фрагментации пакета на сетевом (IP) уровне.
Если IP-узел подключен к каждой из нескольких линий связи, то тогда он должен быть способен обрабатывать поступившие пакеты, имеющие длину, которая превышает канальный MTU-параметр. Стандарт RFC-1981 содержит строгое требование: IPv6-узлы должны обеспечивать значение MTU-параметра более 1280 октетов. Однако, программный IPv6-модуль с минимальным набором функций (например, в загружаемом ПЗУ) может запретить «самому себе» передачу пактов длиной не более чем 1280 октетов, и пренебречь требованием стандарта RFC-1981.
С целью передачи пакета более чем 1280 октетов IPv6-узел может использовать заголовок расширения «Фрагментация» для фрагментирования пакета отправителем с последующей его сборкой у получателя(ей). Тем не менее, применение процедуры фрагментирования является не желательным для какого-либо прикладного процесса, который способен управлять длиной своих сообщений с целью обеспечения необходимого MTU-параметра (то есть, «подгонять» длину к 1280 октетам).
IPv6-узел должен быть способен фрагментировать пакет так, чтобы после его сборки, он имел длину 1500 октетов или больше. Наиболее предпочтительным для IPv6-узла является его способность фрагментировать пакеты, которые при их сборке превышали длину 1500 октетов.
Протокол более высокого уровня или прикладной процесс, зависимые от IPv6-фрагментирования при передаче пакетов длиной, превышающей установленный для канала связи MTU-параметр, не должны отправлять сообщения, которые требуют для их передачи формирование IPv6-пакетов длиной более 1500 октетов, до тех пор, пока не будет гарантии того, что узел/получатель способен собирать пакеты большей длины.
В ответ на переданный IPv4-узлу/получателю IPv6-пакет (то есть, пакет, который прошел процедуру преобразования из IPv6-формата в IPv4-формат) IPv6-узел/отправитель может получить ICMP-сообщение с кодом «Слишком большое сообщение» («Too Big message»), указывающее, что на данном ретрансляционном участке было превышено допустимое значение MTU-параметра, составляющее менее 1280 октетов. В таком случае, IPv6-узлу/отправителю нет необходимости уменьшать размер последующих пакетов до значения менее 1280 октетов. Ему просто необходимо включить в эти пакеты заголовок расширения «Фрагментация» так, чтобы маршрутизатор, осуществляющий процедуру преобразования пакета из IPv6-формата в IPv4-формат, мог формировать подходящее значение идентификационного параметра для его использования IPv4-фрагментах.
Замечание. Это означает, что размер поля полезной нагрузки, возможно, придется уменьшить до 1232 октетов (1280 минус 40 для IPv6-заголовка и 8 для заголовка расширения «Фрагментация»), а может оно будет и менее 1232 октетов, если использовать дополнительные заголовки расширения.
6. Маркеры потоков
20-битовое поле «Маркер потока» («Flow Label») в составе IPv6-заголовка может использоваться отправителем для маркирования последовательностей пакетов, которым требуется специальная обработка IPv6-маршрутизаторами, например, обработка в режиме «не по умолчанию» («non-default quality of service») или обслуживание в масштабе реального времени («real-time»). Этот аспект IPv6-протокола, на момент написания данного стандарта, находился по-прежнему на стадии эксперимента и анализа, и поэтому в дальнейшем станет более очевидным весь набор требований к маркеру потока и его применению. Серверы и маршрутизаторы, которые не поддерживают функцию маркирования потока, должны это поле заполнять нулями, когда пакет направляется на передачу в канал связи, передавать его дальше без изменений при ретрансляции пакета, и игнорировать при получении пакета (см. Приложение 1).
7. Классы трафика
8-битовое поле «Класс трафика» в составе IPv6-заголовка может использоваться узлом/отправителем и/или узлом/ретранслятором (маршрутизатором) для идентификации и распознавания IPv6-пакетов, с точки зрения их принадлежности к различным классам или по их приоритетам. В момент написания данного стандарта, проводилось несколько экспериментов по использованию специализированных битов, определяющих «Тип обслуживания» и/или «Приоритет», для обеспечения различных форм дифференцированного обслуживания IPv4-пакетов, которые не использовали в явном виде маркеры потоков. Поле «Класс трафика» в составе IPv6-заголовка призвано обеспечить аналогичную функциональность IPv6-протокола.
К использованию поля «Класс трафика» предъявляются следующие общие требования:
Программный IPv6-модуль IPv6-узла должен иметь специализированный прикладной интерфейс, через который прикладной процесс будет указывать тип обслуживания формируемого им трафика. Далее этот тип обслуживания будет указываться в поле «Класс трафика» IPv6-заголовка. В режиме «по-умолчанию» это поле (все 8 битов) должно заполняться нулями.
IPv6-узлы, функционально способные использовать несколько или все биты поля «Класс трафика», могут изменять значения этих битов поля в IPv6-пакетах, которые они передают ретранслируют или получают, в соответствие со спецификой их применения. А тем IPv6-узлам, которые не способны использовать поле «Класс трафика», рекомендуется игнорировать это поле и оставлять его без изменений.
Протокол верхнего уровня не должен в обязательном порядке сравнивать значения битов этого поля в принятом пакете с аналогичными битами в отправленном источником пакете.
8. Проблемы протоколов верхних уровней
8.1. Проверочная сумма протоколов транспортного уровня
Любой транспортный или прикладной протоколы, которые включают адреса из IP-заголовка в последовательность данных для вычисления проверочной суммы должны быть модифицированы для «работы» с IPv6-протоколом, и «уметь» включать в обрабатываемую последовательность 128-битовые IPv6-адреса вместо 32-битовых IPv4-адресов. На рис.13 представлен формат «псевдозаголовка» для ТСР- и UDP-протоколов в составе IPv6-заголовка.
32 бита +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Адрес отправителя пакета + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Адрес получателя пакета + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + «Размер блока транспортного уровня» + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | «Идентификатор | | 0 0 0 0 0 0 0 0 0 ... | следующего | | | заголовка» | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.13. Формат «псевдозаголовка» для ТСР- и UDP-протоколов в составе IPv6-заголовка
Если IPv6-пакет содержит заголовок расширения «Маршрутизация», то тогда адрес получателя пакета, используемый в псевдозаголовке, одновременно является и адресом финального получателя пакета. На узле/отправителе этот адрес будет в последнем элементе заголовка расширения «Маршрутизация», а на узле/получателе этот адрес будет в поле «Адрес получателя пакета» IPv6-заголовка.
Значение в поле «Идентификатор следующего заголовка» псевдозаголовка идентифицирует протокол верхнего уровня (для UDP-протокола — «6», для ТСР-протокола — «17»). Это значение будет отличаться от значения в аналогичном поле IPv6-заголовка, если конечно имеют место иные заголовки расширения между IPv6-заголовком и заголовком верхнего уровня.
Поле «Размер блока транспортного уровня» в псевдозаголовке содержит значение длины блока транспортного уровня (например, заголовок ТСР-блока плюс поле полезной нагрузки ТСР-блока). Некоторые протоколы транспортного и прикладного уровней размещают в своих сообщениях данные о длине (размере) этих сообщений (например, в заголовке блока UDP-протокола содержится поле «Полная длина дейтаграммы»). В случае применения таких протоколов значение длины протокольного сообщения размещается в поле «Размер блока транспортного уровня» псевдозаголовка. Другие протоколы (например, ТСР-протокол) не размещают в своих сообщениях данные о длине (размере) этих сообщений. В этом случае в поле «Размер блока транспортного уровня» псевдозаголовка указывается значение, равное значению в поле «Размер поля полезной нагрузки» IPv6-заголовка за вычетом длины всех заголовков расширения, размещённых между IPv6-заголовком и заголовком верхнего уровня.
В отличие от IPv4-протокола, когда IPv6-узлом/отправителем передаются UDP-дейтаграммы, вычисление проверочных сумм этих дейтаграмм является обязательным. Другими словами, если, когда бы то ни было, передается UDP-пакет (то есть IPv6-пакет, содержащий UDP-дейтаграмму), то тогда IPv6-узел/отправитель должен вычислить проверочную сумму данного пакета, используя для этого последовательность октетов, в которую входят сам пакет и псевдозаголовок. Если результат вычисления оказался равным нулю, то тогда 16-битовое поле «Контрольная сумма» в заголовке UDP-дейтаграммы должно заполняться единицами. IPv6-узлы/получатели должны уничтожать UDP-пакет, в котором поле «Контрольная сумма» заголовка UDP-дейтаграммы содержит только одни нули, и после этого они должны регистрировать возникновение нештатной ситуации (ошибки).
Шестая версия ICMP-протокола (ICMPv6) включает рассмотренный выше псевдозаголовок в последовательность октетов, по которой вычисляется проверочная сумма (в этом заключается одно из отличий от ICMPv4, которая не предусматривает включение псевдозаголовка при расчёте проверочной суммы). Причина этого заключается в том, что ICMPv6-сообщения необходимо защитить от ошибочной доставки и искажения тех полей IPv6-заголовка, на которые оно ссылается, так как (в отличие от IPv4-протокола) IPv6-заголовок не входит в последовательность октетов, по которой вычисляется проверочная сумма сетевого уровня Internet-архитектуры. Если значение в поле «Идентификатор следующего заголовка» псевдозаголовка для ICMP-протокола равно «58», то это указывает на наличие ICMPv6-сообщения.
8.2. Максимальное «время жизни» IPv6-пакета
В отличие от IPv4-протокола, IPv6-узлам нет необходимости устанавливать максимальное «время жизни» IPv6-пакета («maximum packet lifetime»). По этой причине поле «Время жизни» («Time to Live») в IPv4-пакете было переименовано в поле «Число ретрансляций» («Hop Limit») в IPv6-пакете. На практике, очень редко, если конечно нет каких-либо специальных задач, когда программные IPv4-модули придерживаются требования относительно ограничения времени существования пакета (причём такая ситуация остается практически неизменной). Любой протокол верхнего уровня, который «доверяет» сетевому (IP) уровню (IPv4- или IPv6-протоколу) процедуру ограничения «время жизни» пакета, должен дополнить набор реализуемых им функций специальными процедурами выявления и уничтожения просроченных пакетов.
8.3. Максимальный размер поля полезной нагрузки в сообщении протокола верхнего уровня
При расчёте максимального размера поля полезной нагрузки в сообщении протокола верхнего уровня, последний должен учитывать наибольший размер IPv6-заголовка относительно IPv4-заголовка. Например, в IPv4-протоколе существует специальная процедура расчёта максимального размера ТСР-блока (MSS — maximum segment size), в соответствие с которой этот размер рассчитывается как максимальный размер пакета (либо значение в режиме «по-умолчанию», либо значение MTU-параметра) минус 40 октетов (из которых 20 октетов для IPv4-заголовка минимальной длины и 20 октетов для ТСР-заголовка минимальной длины). Если ТСР-протокол используется совместно с IPv6-протоколом, то тогда MSS должен рассчитываться как максимальный размер пакета минус 60 октетов, так как минимальный размер IPv6-заголовка (то есть, IPv6-заголовок без заголовков расширения) на 20 октетов длиннее, чем IPv4-заголовок минимальной длины.
8.4. Ответная реакция на принятые пакеты, содержащие заголовки расширения «Маршрутизация»
Если протокол верхнего уровня передает один или несколько сообщений, преобразуемые на сетевом уровне в IPv6-пакеты, в ответ на принятое сообщение, переданное с помощью IPv6-пакета, содержащего заголовок «Маршрутизация», то тогда ответный(е) IPv6-пакет(ы) не должны содержать заголовок «Маршрутизация», который был автоматически извлечен из принятого IPv6-пакета. Однако все сказанное выше не относится к процедурам проверки целостности и аутентификации IP-адреса узла/отправителя и заголовка «Маршрутизация» (например, на основе использования заголовка расширения «Аутентификация» в принятом пакете). Другими словами, допускается передача только следующих типов пакетов в ответ на принятый пакет, содержащий заголовок «Маршрутизация»:
Ответные пакеты, не содержащие заголовков «Маршрутизация».
Ответные пакеты, содержащие заголовков «Маршрутизация», но только не те, которые были извлечены из принятого пакета (например, заголовок «Маршрутизация», который используется для локальной настройки).
Ответные пакеты, содержащие заголовков «Маршрутизация», но только те, которые были извлечены из принятого пакета узлом/получателем и прошли в обязательном порядке на узле/получателе процедуры проверки целостности и аутентификации IP-адреса узла/отправителя и заголовка «Маршрутизация».
Приложение A. Семантика и использование поля «Маркер потока»
Под потоком понимается последовательность IP-пакетов, которые были переданы соответствующим узлом/отправителем соответствующему узлу/получателю (с использованием однонаправленных или групповых IP-адресов). При этом узел/отправитель определил для переданных пакетов специальную процедуру обработки, которую будут реализовывать промежуточные маршрутизаторы. Конкретная процедура обработки может быть инсталлирована в маршрутизаторы с помощью соответствующего протокола управления (например, протокол резервирования ресурса или с помощью информации содержащейся в самих поточных пакетах, в частности с помощью ретрансляционной функции «hop-by-hop»). Однако детальное описание таких протоколов управления не является объектом данного стандарта.
В принципе, одновременно может существовать несколько потоков пакетов от отправителя к получателю, а также иной трафик, который не связан с каким-либо потоком. Поток однозначно идентифицируется парой значений, а именно адресом отправителя пакета и ненулевым маркером потока. Пакеты, которые не принадлежат какому-либо потоку, содержат нулевое значение в поле «Маркер потока».
Маркер потока присваивается потоку узлом/отправителем этого потока пакетов. Новый маркер потока должен выбирать случайным (псевдослучайным) образом и равномерно в диапазоне «1…FFFF» (шестнадцатеричная запись). Целью случайного выбора является обеспечение произвольного набора битов в поле «Маркер потока», который был бы приемлем для использования его маршрутизаторами в качестве случайного ключевого слова при определении режима обработки, необходимого для этого потока.
Все пакеты, принадлежащие одному и тому же потоку, должны передаваться с одними и теми же адресом отправителя/получателя и маркером потока. Если какой-либо из этих пакетов включает заголовок расширения «Дополнительные функции: ретрансляция», то тогда они все должны отправляться для передачи с одним и тем же содержанием в этом заголовке (за исключением поля «Идентификатор следующего заголовка» в заголовке «Дополнительные функции: ретрансляция»).
Если какой-либо из этих пакетов включает заголовок расширения «Маршрутизация», то тогда все передаваемые пакеты должны иметь во всех без исключения заголовках расширения одно и то же содержание, включая заголовок «Маршрутизация» (за исключением поля «Идентификатор следующего заголовка» в заголовке «Маршрутизация»). Маршрутизаторы или узлы/получатели должны (но это не является обязательным требованием) осуществлять проверку соблюдения этих условий. Если будет обнаружено нарушение этих условий, то тогда целесообразно направить узлу/отправителю ICMP-сообщение с кодом «0» («Параметрическая проблема»), указав на октет высшего порядка в поле «Маркер потока» (то есть значение «1» внутри IPv6-пакета).
Максимальное время существования любого режима управления потоком на маршруте его доставки должно быть определено в описании механизма управления потоком, например, в протоколе резервирования ресурса или с помощью ретрансляционной функции «hop-by-hop» путём её настройки в режим обработки потока пакетов. Узел/отправитель не должен повторно использовать маркер потока для идентификации нового потока пакетов в пределах максимального времени существования любого режима управления потоком, которое могло быть установлено для использования уже назначенного маркера потока.
Когда IP-узел перешел в режим остановки и последующего рестарта (например, в результате сбоя в работе), он должен быть «внимательным», чтобы не использовать ранее назначенный маркер потока, время существования которого ещё не закончилось. Для этого необходимо, либо использовать процедуру записи маркера потоков в ПЗУ, которое должно быть устойчивым при возникновении нештатных ситуаций (в частности, сбоев в работе), либо отказаться от использования каких-либо маркеров потоков до тех пор, пока не истечёт максимальное время «жизни» любых возможных ранее установленных режимов обработки потоков. Если же известно минимальное время, по истечении которого операционная система IP-узла должна быть перезагружена, то тогда это время может быть вычтено из необходимого времени ожидания до начала процедуры назначения маркеров потоков.
Не существует требования, чтобы все, или даже большинство пакетов принадлежали каким-либо потокам, то есть содержали ненулевые поля «Маркер потока». Это замечание отражено в данном стандарте для того, чтобы напомнить разработчикам протоколов и программного обеспечения, что не стоит предполагать обратного. Например, было не разумным создавать маршрутизатор, который бы функционировал только тогда, когда большинство передаваемых пакетов принадлежало потокам, либо разрабатывать способ сжатия заголовка, который бы «работал» только с пакетами, принадлежащими тем или иным потокам.
Приложение B. Правила форматирования для дополнительных функций
В данном приложении приводятся рекомендации, как формировать поля при создании новых дополнительных функций с использованием заголовков расширения «Дополнительные функции: узел-получатель» или «Дополнительные функции: ретрансляция» (как определено в 4.2). Эти рекомендации основаны на следующих предположениях:
Первое необходимое свойство заключается в следующем. Любые субполя, состоящие из нескольких октетов, в пределах поля «Данные дополнительной функции» размещаются в своих естественных границах, то есть субполя длиной n октетов должны размещаться в последовательности, равной целому числу отрезков из n октетов, от начала заголовков расширения «Дополнительные функции: узел-получатель» или «Дополнительные функции: ретрансляция», где n = 1, 2, 4 или 8.
Второе необходимое свойство заключается в следующем. Заголовки расширения «Дополнительные функции: узел-получатель» или «Дополнительные функции: ретрансляция» должны формироваться как можно более короткими с соблюдением обязательного требования — иметь длину, равную целому числу 8-октетных отрезков.
И последнее. Когда имеет место тот или иной заголовок расширения для указания дополнительных функций, они должны содержать как можно меньше дополнительных функций, как правило, одну.
Эти свойства предполагают следующий подход к формированию полей для указания дополнительных функций: порядок следования полей — от наименьшего к наибольшему, без какого-либо дополнения нулями внутри полей, затем устанавливается требование к разметке всего поля дополнительной функции, основываясь на требовании к разметке наибольшего поля (максимальная длина разметки должна составлять 8 октетов). Этот подход продемонстрирован на следующих трёх примерах:
Пример №1
Если для дополнительной функции «Х» требуется два поля данных, причем одно длиной 8 октетов, а второе — 4 октета, то тогда возможные кодирование и разметка представлена на рис.14(а).
В данном случае, разметка должна подчиняться условию «8n+2», так как это должно гарантировать, что 8-октетное поле начнётся как отрезок последовательности, кратной 8 октетам, от начала вложенного заголовка. Полный заголовок расширения «Дополнительные функции: узел-получатель» или «Дополнительные функции: ретрансляция», содержащий одну дополнительную функцию мог бы иметь формат, представленный на ри.14(б);
32 бита
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Тип дополнительной | Длина поля «Данные |
| функции («Х») | дополнительной |
| | функции» («12 октетов») |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 4-октетное поле +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 8-октетное поле +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис.14(а). Пример №1
32 бита +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина данного заголовка | Тип дополнительной | Длина поля «Данные | | следующего заголовка» | расширения («1») | функции («Х») | дополнительной | | | | | функции» («12 октетов») | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 4-октетное поле + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 8-октетное поле + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.14(б). Пример №1
Пример №2
Если для дополнительной функции «Y» требуется три поля данных, причем одно длиной 4 октетов, второе — 2 октета, а третье — 1 октет, то тогда возможные кодирование и разметка представлена на рис.15(а).
32 бита
+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Тип дополнительной |
| функции («Y») |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Длина поля «Данные | | |
| дополнительной | 1-октетное поле | 2-октетное поле |
| функции» («12 октетов») | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 4-октетное поле +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис.15(а). Пример №2
В данном случае, разметка должна подчиняться условию «4n+3», так как это должно гарантировать, что 4-октетное поле начнётся как отрезок последовательности, кратной 4 октетам, от начала вложенного заголовка. Полный заголовок расширения «Дополнительные функции: узел-получатель» или «Дополнительные функции: ретрансляция», содержащий одну дополнительную функцию мог бы иметь формат, представленный на ри.15(б).
32 бита +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина данного заголовка | «Дополнительная функция | Тип дополнительной | | следующего заголовка» | расширения («1») | дополнения нулями: | функции («Y») | | | | Pad1» («0») | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Длина поля «Данные | | | | дополнительной | 1-октетное поле | 2-октетное поле | | функции» («7 октетов») | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 4-октетное поле + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Дополнительная функция | Длина данного заголовка | | | | дополнения нулями: | расширения («2») | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | | PadN» («1») | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.15(б). Пример №2
Пример №3
Заголовок расширения «Дополнительные функции: узел-получатель» или «Дополнительные функции: ретрансляция», содержащий обе дополнительные функции «Х» и «Y» из примеров №1 и №2, мог бы иметь кодирование и разметку, представленные на рис.16(а,б).
32 бита +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина данного | Тип дополнительной | Длина поля «Данные | | следующего заголовка» | заголовка расширения | функции («X») | дополнительной | | | («3 октета») | | функции» («12 октетов») | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 4-октетное поле + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 8-октетное поле + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Дополнительная функция | Длина данного заголовка | | Тип дополнительной | | дополнения нулями: | расширения («1») | 0 0 0 0 0 0 0 0 | функции («Y») | | PadN» («1») | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Длина поля «Данные | | | | дополнительной | 1-октетное поле | 2-октетное поле | | функции» («7 октетов») | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 4-октетное поле + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Дополнительная функция | Длина данного заголовка | | | | дополнения нулями: | расширения («2») | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | | PadN» («1») | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.16(а). Пример №3
32 бита +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Идентификатор | Длина данного | «Дополнительная функция | Тип дополнительной | | следующего заголовка» | заголовка расширения | дополнения нулями: | функции («Y») | | | («3 октета») | Pad1» («0») | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Длина поля «Данные | | | | дополнительной | 1-октетное поле | 2-октетное поле | | функции» («7 октетов») | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 4-октетное поле + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | «Дополнительная функция | Длина данного | | | | дополнения нулями: | заголовка расширения | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | | PadN» («1») | («4 октета») | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Тип дополнительной | Длина поля «Данные | | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | функции («X») | дополнительной | | | | | функции» («12 октетов») | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 4-октетное поле + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 8-октетное поле + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.16(б). Пример №3
Вопросы безопасности
The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401].
Благодарности
The authors gratefully acknowledge the many helpful suggestions of the members of the IPng working group, the End-to-End Protocols research group, and the Internet Community At Large.
Ссылки
| [RFC-2401] | Kent, S. и R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, Ноябрь 1998. |
| [RFC-2402] | Kent, S. и R. Atkinson, «IP Authentication Header», RFC 2402, Ноябрь 1998. |
| [RFC-2406] | Kent, S. и R. Atkinson, «IP Encapsulating Security Protocol (ESP)», RFC 2406, Ноябрь 1998. |
| [ICMPv6] | A. Conta и S. Deering, «Протокол передачи управляющих сообщений (ICMPv6) для 6-ой версии IP-протокола (IPv6)», RFC 2463, Декабрь 1998. |
| [ADDRARCH] | Hinden, R. и S. Deering, «IP Version 6 Addressing Architecture», RFC 2373, Июль 1998. |
| [RFC-1981] | McCann, J., Mogul, J. и S. Deering, «Path MTU Discovery for IP version 6», RFC 1981, Август 1996. |
| [RFC-791] | J. Postel, «Протокол IP (Internet Protocol)», RFC 791, Сентябрь 1981. |
| [RFC-1700] | Reynolds, J. и J. Postel, «Assigned Numbers», STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html |
| [RFC-1661] | Simpson, W., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, Июль 1994. |