RFC-2460. Шестая версия протокола межсетевого обмена в Internet (IPv6-адресация). Декабрь 1998 года (категория: стандарт)

Подождите немного. Документ загружается.

RFC-2460 декабрь 1998

года

категория: стандарт

ШЕСТАЯ ВЕРСИЯ ПРОТОКОЛА МЕЖСЕТЕВОГО

ОБМЕНА В INTERNET

(IPv6-адресация)

I . ПРЕДИСЛОВИЕ

Этот стандарт определяет шестую версию протокола сетевого уровня в

Internet



(IP-протокол), являясь приемником четвертой версии IP-протокола

(IPv4-адресация). Эти версии IP-протокола отличаются в следующих

категориях:

 расширение адресного пространства . IPv6-протокол увеличивает размер

IP-адреса с 32 до 128 битов с целью обеспечения нескольких уровней

иерархии в пространстве адресов, увеличения числа IP-узлов, которым

может быть присвоен IP-адрес, и упрощения автоматической настройки

адресов. Значительно возрастает масштабируемость групповой

маршрутизации, за счёт включения специализированного поля

“Диапазон” в групповые IPv6-адреса. А также введён новый тип адресов,

именуемый “альтернативным”, который используется для доставки

пакетов в одну из любых групп IP-узлов;

 упрощение формата заголовка . Некоторые поля заголовка IPv4-пакета

были поделены или стали дополнительными с целью снижения общих

затрат на обработку пакета и для ограничения затрат, связанных с

используемой шириной полосы пропускания, необходимой для доставки

заголовка IPv6-пакета;

 значительное улучшение поддержки функций расширения и иных

дополнительных функций. Изменения в способе кодирования

дополнительных функций в заголовке IPv6-пакета позволили увеличить

эффективность доставки, устранить предельные границы на размер полей

для дополнительных функций и существенно повысить гибкость при

введении новых дополнительных функций в дальнейшем;

 функция маркирования потока IP v 6-пакетов . Эта новая функция была

введена с целью маркирования пакетов, принадлежащих

соответствующим “потокам” трафика, по отношению к которым

передающая сторона требует специализированной обработки, например,

обеспечение качества обслуживания в режиме “не по-умолчанию” (“non-



Данный стандарт определяет только логическую характеристику IP-протокола, то есть формат (структуру)

IP-пакета и правила кодирования его внутренних полей.

default quality of service”) или обслуживание в масштабе реального

времени (“real-time”);

 функции аутентификации и обеспечения безопасности . Для IPv6-пакетов

стандартизированы функции аутентификации, обеспечения целостности и

конфиденциальности данных.

II. ТЕРМИНОЛОГИЯ

 IP-узел (node) — аппаратно-программный комплекс, реализующий IPv6-

протокол;

 маршрутизатор (router) — IP-узел, который доставляет IPv6-пакеты, не

адресованные ему самому в явном виде



;

 сервер (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) — максимальный размер пакета в октетах, который может быть

передан по конкретной линии (каналу) связи;



Это свойство маршрутизатора не касается специализированных IP-пакетов управления самим

маршрутизатором, передаваемых в соответствии с SNMP-протоколом (Simple Network Management Protocol).

 максимально допустимый размер передаваемой единицы данных для

конкретного маршрута доставки (path MTU) — линия (канал) связи с

наименьшим значением MTU среди всех линий (каналов) связи,

входящих в маршрут (может состоять из нескольких ретрансляционных

участков) доставки пакета между IP-узлом отправителем и IP-узлом

получателем.

(Замечание. Существует возможность, хотя это весьма странно, что

после настройки сетевого устройства с несколькими интерфейсами оно

будет, с одной стороны, транслировать не предназначенные ему IP-

пакеты, которые поступили из некоторой совокупности его же

интерфейсов (но не от всех), а с другой стороны, оно будет уничтожать

не предназначенные ему IP-пакеты, которые поступили из других

оставшихся интерфейсов. Такое устройство должно удовлетворять

требованиям протокола для маршрутизаторов при получении IP-пакетов

из интерфейсов, предназначенных для ретрансляции пакетов, а также

при взаимодействии с соседними сетевыми устройствами через эти же

интерфейсы. Такое устройство должно удовлетворять требованиям

протокола для серверов при получении IP-пакетов из интерфейсов,

предназначенных для уничтожения пакетов, а также при взаимодействии

с соседними сетевыми устройствами через эти же интерфейсы.)

III . ФОРМАТ ЗАГОЛОВКА IP V 6-ПАКЕТА

На рис.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-пакете представлен заголовок маршрутизации.)

IV . ЗАГОЛОВКИ РАСШИРЕНИЯ В IP V 6 -ПАКЕТЕ

В IPv6-протоколе предусмотрена доставка дополнительной (служебной)

закодированной информации сетевого уровня, которая может быть размещена в

IPv6-пакете между IPv6-заголовоком и заголовком верхнего уровня. Для такой

доставки существует несколько так называемых заголовков расширения,

причём каждый из них идентифицируется собственным значением в поле

“Следующий заголовок”. На рис.2 приведены примеры нескольких заголовков

расширения в IPv6-пакетах.

IPv6-заголовок

“Следующий заголовок” =

ТСР

TCP-заголовок + данные

IPv6-заголовок

“Следующий заголовок” =

Routing

Заголовок

маршрутизации

“Следующий заголовок”

ТСР

TCP-заголовок + данные

IPv6-заголовок

“Следующий заголовок” =

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):

 “Тип дополнительной функции” (“Option Type”) — 8-битовое беззнаковое

целое число, которое представляет идентификатор, определяющий тип

дополнительной функции;

 “Длина поля “Данные дополнительной функции” (“Opt Data Len”) — 8-

битовое беззнаковое целое число, которое определяет длину поля

“Данные дополнительной функции” в октетах;

 “Данные дополнительной функции” (“Option Data”) — поле переменной

длины, содержащее специфические данные дополнительной функции.

Тип дополнительной

функции

Длина поля “Данные

дополнительной функции”

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

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

Последовательность дополнительный функций в рамках заголовка

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

Приёмный модуль никогда не должен, например, сканировать весь заголовок в

поисках соответствующего типа дополнительной функции и реализовывать

найденный функцию прежде всех остальных функций.

Кодирование идентификаторов, определяющих тип дополнительной

функции, имеет следующее правило. Два старших бита идентификатора

должны выбираться таким образом, чтобы 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). (Замечание. Формат такого типа дополнения

является специальным случаем, то есть он не имеет полей для

указания длины и значения параметра.) Этот тип функции

используется для вставки только одного октета в качестве дополнения

последовательности заголовка, описывающей дополнительную функцию.

Если же необходимо использовать несколько октетов дополнения

последовательности, то тогда целесообразно использовать второй тип

функции дополнения “PadN”, а не несколько раз первый тип “Pad1”;

8 битов

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

 второй тип дополнения (“PadN”) — требования к структуре формата

отсутствуют (рис.5). Этот тип функции используется для вставки двух

или более октетов в качестве дополнения последовательности заголовка,

описывающей дополнительную функцию. Для дополнения из “N”

октетов, поле “Длина поля “Данные дополнительной функции” будет

содержать значение “N-2”, а само поле “Данные дополнительной

функции” будет состоять из “N-2” нулевых октетов.

Длина поля “Данные

дополнительной

функции”

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

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

§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. Заголовок расширения “Маршрутизация”