Максимальный размер поля данных для

4.4.1.1 Адресация IPv6

Семенов Ю.А. (ГНЦ ИТЭФ)

1. Терминология 2. Формат заголовка IPv6 3.

IP версия 6 архитектуры адресации 4. Модель адресации 4.1. Представление записи адресов (текстовое представление адресов) 4.2. Представление типа адреса 4.3. Уникастные адреса 4.3.1. Примеры уникастных адресов 4.4. Неспецифицированный адрес 4.5. Адрес обратной связи 4.6. IPv6 адреса с вложенными IPv4 адресами 4.7. NSAP адреса 4.8. IPX Адреса 4.9. Провайдерские глобальные уникаст-адреса 4.10. Локальные уникаст-адреса IPv6 4.11. Эникаст-адреса 4.12. Мульткаст-адреса 4.12.1. Предопределенные мультикаст-адреса 4.13. Необходимые адреса узлов 5. Заголовки расширения IPv6 5.1. Порядок заголовков расширения 6. Опции 6.1. Опции заголовка hop-by-hop (шаг за шагом) 7. Маршрутный заголовок 8. Заголовок фрагмента 9. Заголовок опций места назначения 10. Отсутствие следующего заголовка 11. О размере пакетов 12. Метки потоков 13. Приоритет 14. О протоколе верхнего уровня 14.1 Контрольные суммы верхнего уровня 15. Максимальное время жизни пакета 16. Максимальный размер поля данных для протоколов высокого уровня 17. Приложение A. Рекомендации по формированию опций 18. Соображения безопасности 19. Расширение DNS для поддержки IP версии 6 19.1. Определение новой ресурсной записи и домена 19.2. Модификации существующих типов запроса 20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6 20.1. ICMPv6 (ICMP для IPv6) 20.2. Общий формат сообщений 20.3. Сообщения об ошибках ICMPv6 20.4. Информационные сообщения icmpv6 В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: “TCP and UDP with Bigger Addresses (TUBA)”; “Common Architecture for the Internet (CatnIP)” и “Simple Internet Protocol Plus (SIPP) [смотри “Протоколы и ресурсы Интернет” Семенов Ю.А., Радио и связь, М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.

Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет).

IANA будет делегировать права выдачи IP-адресов региональным сервис-провайдерам, субрегиональным структурам и организациям. Отдельные лица и организации могут получить адреса непосредственно от регионального распределителя или сервис провайдера.

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

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

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

Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям.

IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:

Расширение адресации

В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.

Спецификация формата заголовков

Некоторые поля заголовка IPv4 отбрасываются или делаются опционными, уменьшая издержки, связанные с обработкой заголовков пакетов с тем, чтобы уменьшить влияние расширения длины адресов в IPv6.

Улучшенная поддержка расширений и опций

Изменение кодирования опций IP-заголовков позволяет облегчить переадресацию пакетов, ослабляет ограничения на длину опций, и делает более доступным введение дополнительных опций в будущем.

Возможность пометки потоков данных

Введена возможность помечать пакеты, принадлежащие определенным транспортным потокам, для которых отправитель запросил определенную процедуру обработки, например, нестандартный тип TOS (вид услуг) или обработка данных в реальном масштабе времени.

Идентификация и защита частных обменов

В IPv6 введена спецификация идентификации сетевых объектов или субъектов, для обеспечения целостности данных и при желании защиты частной информации.

Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.

1. Терминология

Узел	Оборудование, использующее IPv6.
Маршрутизатор	Узел, который переадресует пакеты ipv6, которые не адресованы ему непосредственно.
ЭВМ	Любой узел, который не является маршрутизатором.
Верхний уровень	Протокольный уровень, расположенный непосредственно поверх. В качестве примеров можно привести транспортные протоколы TCP и UDP, протокол управления ICMP, маршрутные протоколы типа OSPF (RFC-2740), а также интернетовские или другие протоколы нижнего уровня инкапсулированные в IPv6, например, IPX, Appletalk, или сам IPv6.
Канал	Средство коммуникации или среда, через которую узлы могут взаимодействовать друг с другом на связном уровне, т.е., уровень непосредственно под IPv6. Примерами могут служить Ethernet; PPP; X.25, Frame Relay, или ATM; а также Интернет "туннели", такие как туннели поверх IPv4 или IPv6.
Соседи	Узлы, подключенные к общему каналу.
Интерфейс	Средство подключения узла к каналу.
Адрес	Идентификатор IPv6-уровня для интерфейса или набора интерфейсов.
Пакет	Заголовок и поле данных IPv6.
MTU канала	Максимальный размер пакета в канале
MTU пути	Минимальный MTU канала для пути от узла источника до получателя.
Эникастный адрес	Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по такому адресу, доставляется ближайшему интерфейсу (согласно метрики маршрутного протокола) из числа идентифицированных этим адресом.

<

/p> Замечание: допустимо (хотя и необычно), что устройство с несколькими интерфейсами может быть сконфигурировано для переадресации пакетов, приходящих через один или несколько интерфейсов. Пакеты, приходящие через остальные интерфейсы, могут при этом отбрасываться. Такие устройства должны выполнять требования протоколов маршрутизации. При получении пакетов, адресованных этому устройству, оно должно вести себя как обычная ЭВМ.

2. Формат заголовка IPv6

Рис. 4.4.1.1.1. Формат заголовка пакета IPv6

Версия	4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6)
Приор .	4-битный код приоритета
Метка потока	24-битный код метки потока (для мультимедиа)
Размер поля данных	16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций.
Следующий заголовок	8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700].
Предельное число шагов	8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется.
Адрес отправителя	128-битовый адрес отправителя пакета. См. RFC-1884.
Адрес получателя	128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884.

3. IP версия 6 архитектуры адресации

Существует три типа адресов:

unicast:	Идентификатор одиночного интерфейса. Пакет, посланный по уникастному адресу, доставляется интерфейсу, указанному в адресе.
anycast:	Идентификатор набора интерфейсов (принадлежащих разным узлам). Пакет, посланный по эникастному адресу, доставляется одному из интерфейсов, указанному в адресе (ближайший, в соответствии с мерой, определенной протоколом маршрутизации).
multicast:	Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по мультикастинг-адресу, доставляется всем интерфейсам, заданным этим адресом.

<

/p> В IPv6 не существует широковещательных адресов, их функции переданы мультикастинг-адресам.

В IPv6, все нули и все единицы являются допустимыми кодами для любых полей, если не оговорено исключение.

4. Модель адресации

ipv6 адреса всех типов ассоциируются с интерфейсами, а не узлами. Так как каждый интерфейс принадлежит только одному узлу, уникастный адрес интерфейса может идентифицировать узел.

IPv6 уникастный адрес соотносится только с одним интерфейсом. Одному интерфейсу могут соответствовать много IPv6 адресов различного типа (уникастные, эникастные и мультикстные). Существует два исключения из этого правила:

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

Маршрутизаторы могут иметь ненумерованные интерфейсы (например, интерфейсу не присваивается никакого IPv6 адреса) для соединений точка-точка, чтобы исключить необходимость вручную конфигурировать и объявлять (advertise) эти адреса. Адреса не нужны для соединений точка-точка маршрутизаторов, если эти интерфейсы не используются в качестве точки отправления или назначения при посылке IPv6 дейтограмм. Маршрутизация здесь осуществляется по схеме близкой к используемой протоколом CIDR в IPv4.

IPv6 соответствует модели IPv4, где субсеть ассоциируется с каналом. Одному каналу могут соответствовать несколько субсетей.

4.1. Представление записи адресов (текстовое представление адресов)

Существует три стандартные формы для представления ipv6 адресов в виде текстовых строк:

Основная форма имеет вид x:x:x:x:x:x:x:x, где 'x' шестнадцатеричные 16-битовые числа.

Из-за метода записи некоторых типов IPv6 адресов, они часто содержат длинные последовательности нулевых бит. Для того чтобы сделать запись адресов, содержащих нулевые биты, более удобной, имеется специальный синтаксис для удаления лишних нулей. Использование записи "::" указывает на наличие групп из 16 нулевых бит. Комбинация "::" может появляться только при записи адреса. Последовательность "::" может также использоваться для удаления из записи начальных или завершающих нулей в адресе. Например:

1080:0:0:0:8:800:200c:417a	уникаст-адрес
ff01:0:0:0:0:0:0:43	мультикаст адрес
0:0:0:0:0:0:0:1	адрес обратной связи
0:0:0:0:0:0:0:0	неспецифицированный адрес

1080::8:800:200c:417a	уникаст-адрес
ff01::43	мультикаст адрес
::1	адрес обратной связи
::	не специфицированный адрес

Альтернативной формой записи, которая более удобна при работе с ipv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где 'x' шестнадцатеричные 16-битовые коды адреса, а 'd' десятичные 8-битовые, составляющие младшую часть адреса (стандартное IPv4 представление). Например:

0:0:0:0:0:0:13.1.68.3

0:0:0:0:0:FFFF:129.144.52.38

или в сжатом виде:

::13.1.68.3

::FFFF:129.144.52.38

4.2. Представление типа адреса

Специфический тип IPv6 адресов идентифицируется лидирующими битами адреса. Поле переменной длины, содержащее эти лидирующие биты, называется префиксом формата (Format Prefix - FP). Исходное назначение этих префиксов следующее (табл. 4.4.1.1.1):

Таблица 4.4.1.1.1

Назначение	Префикс (двоичный)	Часть адресного пространства
Зарезервировано	0000 0000	1/256
Не определено	0000 0001	1/256
Зарезервировано для NSAP	0000 001	1/128
Зарезервировано для IPX	0000 010	1/128
Не определено	0000 011	1/128
Не определено	0000 1	1/32
Не определено	0001	1/16
Не определено	001	1/8
Провайдерские уникаст-адреса	010	1/8
Не определено	011	1/8
Зарезервировано для географических уникаст-адресов	100	1/8
Не определено	101	1/8
Не определено	110	1/8
Не определено	1110	1/16
Не определено	1111 0	1/32
Не определено	1111 10	1/64
Не определено	1111 110	1/128
Не определено	1111 1110 0	1/512
Локальные канальные адреса	1111 1110 10	1/1024
Локальные адреса (site)	1111 1110 11	1/1024
Мультикаст-адреса	1111 1111	1/256

Замечание: Не специфицированные адреса, адреса обратной связи и IPv6 адреса со встроенными IPv4 адресами, определены вне “0000 0000” префиксного пространства.

Данное распределение адресов поддерживает прямое выделение адресов провайдера, адресов локального применения и мультикастинг-адресов. Зарезервировано место для адресов NSAP, IPX и географических адресов. Оставшаяся часть адресного пространства зарезервирована для будущего использования. Эти адреса могут использоваться для расширения имеющихся возможностей (например, дополнительных адресов провайдеров и т.д.) или новых приложений (например, отдельные локаторы и идентификаторы). Пятнадцать процентов адресного пространства уже распределено. Остальные 85% зарезервированы.

Уникастные адреса отличаются от мультикастных значением старшего октета: значение FF (11111111) идентифицирует мультикастинг-адрес; любые другие значения говорят о том, что адрес уникастный. Эникастные (anycast) адреса берутся из уникастного пространства, и синтаксически неотличимы от них.

4.3. Уникастные адреса

IPv6 уникастный адреса, сходны с традиционными IPv4 адресами при бесклассовой междоменной маршрутизации (Class-less InterDomain Routing - CIDR).

Существует несколько форм присвоения уникастных адресов в IPv6, включая глобальный уникастный адрес провайдера (global provider based unicast address), географический уникастный адрес, NSAP адрес, IPX иерархический адрес, Site-local-use адрес, Link-local-use адрес и IPv4-compatible host address. В будущем могут быть определены дополнительные типы адресов.

Узлы IPv6 могут иметь существенную или малую информацию о внутренней структуре IPv6 адресов, в зависимости от выполняемой узлом роли, (например, ЭВМ или маршрутизатор). Как минимум, узел может считать, что уникастный адрес (включая его собственный адрес) не имеет никакой внутренней структуры. То есть представляет собой 128 битовый неструктурированный образ.

ЭВМ может дополнительно знать о префиксе субсети для каналов, c которыми она соединена, где различные адреса могут иметь разные значения n:

Рис. 4.4.1.1.2

Более сложные ЭВМ могут использовать и другие иерархические границы в уникастном адресе. Хотя простейшие маршрутизаторы могут не знать о внутренней структуре IPv6 уникастных адресов, маршрутизаторы должны знать об одной или более иерархических границах для обеспечения работы протоколов маршрутизации. Известные границы для разных маршрутизаторов могут отличаться и зависят от того, какое положение занимает данный прибор в иерархии маршрутизации.

4.3.1. Примеры уникастных адресов

Примером уникастного адресного формата, который является стандартным для локальных сетей и других случаев, где применимы MAC адреса, может служить:

Рис. 4.4.1.1.3

Где 48-битовый идентификатор интерфейса представляет собой IEEE-802 MAC адрес. Использование IEEE 802 mac адресов в качестве идентификаторов интерфейсов будет стандартным в среде, где узлы имеют IEEE 802 MAC адреса. В других средах, где IEEE 802 MAC адреса не доступны, могут использоваться другие типы адресов связного уровня, такие как E.164 адреса, в качестве идентификаторов интерфейсов.

Включение уникального глобального идентификатора интерфейса, такого как IEEE MAC адрес, делает возможным очень простую форму авто-конфигурации адресов. Узел может узнать идентификатор субсети, получая информацию от маршрутизатора в виде сообщений оповещения, которые маршрутизатор посылает связанным с ним партнерам, и затем сформировать IPv6 адрес для себя, используя IEEE MAC адрес в качестве идентификатора интерфейса для данной субсети.

Другой формат уникастного адреса относится к случаю, когда локальная сеть или организация нуждаются в дополнительных уровнях иерархии. В этом примере идентификатор субсети делится на идентификатор области и идентификатор субсети. Формат такого адреса имеет вид:

Рис. 4.4.1.1.4

Эта схема может быть развита с тем, чтобы позволить локальной сети или организации добавлять новые уровни внутренней иерархии. Может быть, желательно использовать идентификатор интерфейса меньше чем 48-разрядный IEEE 802 MAC адрес, с тем, чтобы оставить больше места для полей, характеризующих уровни иерархии. Это могут быть идентификаторы интерфейсов, сформированные администрацией локальной сети или организации.

4.4. Не специфицированный адрес

Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу. Этот адрес указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтограммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес.

Не специфицированный адрес не должен использоваться в качестве указателя места назначения IPv6 дейтограмм или в IPv6 заголовках маршрутизации.

4.5. Адрес обратной связи

Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обратной связи. Он может использоваться для посылки IPv6 дейтограмм самому себе. Его нельзя использовать в качестве идентификатора интерфейса.

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

4.6. IPv6 адреса с вложенными IPv4 адресами

Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6 пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется "IPv4-compatible IPv6 address" и имеет формат, изображенный на рис. 4.4.1.1.5:

Рис. 4.4.1.1.5

Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется "IPv4-mapped IPv6 address" и имеет формат показанный на рис. 4.4.1.1.6:

Рис. 4.4.1.1.6

4.7. NSAP адреса

Соответствие NSAP адреса IPv6 адресам выглядит следующим образом (рис. 4.4.1.1.7):

Рис. 4.4.1.1.7

4.8. IPX Адреса

Соответствие IPX и IPv6 адресов показано ниже на рис. 4.4.1.1.8:

Рис. 4.4.1.1.8

4.9. Провайдерские глобальные уникаст-адреса

Глобальный уникаст-адрес провайдера имеет назначение, описанное в [ALLOC]. Исходное назначение этих уникаст-адресов аналогично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобальный IPv6 уникаст-адрес провайдера имеет формат, отображенный ниже на рис. 4.4.1.1.9:

Рис. 4.4.1.1.9. Глобальный адрес провайдера

Старшая часть адреса предназначена для определения того, кто определяет часть адреса провайдера, подписчика и т.д.

Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле идентификатор регистрации (ID).

Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая идентификатора провайдера.

Идентификатор подписчика позволяет разделить подписчиков, подключенных к одному и тому же провайдеру. Термин "префикс подписчика" относится к старшей части адреса, включая идентификатор подписчика.

Часть адреса интра-подписчик определяется подписчиком и организована согласно местной топологии Интернет подписчика. Возможно, что несколько подписчиков пожелают использовать область адреса интра-подписчик для одной и той же субсети и интерфейса. В этом случае идентификатор субсети определяет специфический физический канал, а идентификатор интерфейса - определенный интерфейс субсети.

4.10. Локальные уникаст-адреса IPv6

Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 4.4.1.1.10:

Рис. 4.4.1.1.10. Локальный адрес канала

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

Рис. 4.4.1.1.11. Локальный адрес сети

Локальные адреса сети могут использоваться для локальных сетей или организаций, которые (пока еще) не подключены к глобальному Интернет. Им не нужно запрашивать или “красть” префикс адреса из глобального адресного пространства Интернет. Вместо этого можно использовать локальный адрес сети IPv6. Когда организация соединяется с глобальным Интернет, она может сформировать глобальные адреса путем замещения локального префикса сети префиксом подписчика.

Маршрутизаторы не должны переадресовывать пакеты с локальными адресами сети отправителя.

4.11. Эникаст-адреса

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

Эникастные адреса выделяются из уникастного адресного пространства, и используют один из известных уникастных форматов. Таким образом эникастные адреса синтаксически неотличимы от уникастных адресов. Когда уникастный адрес приписан более чем одному интерфейсу, он превращается в эникастный адрес и узлы, которым он приписан, должны быть сконфигурированы так, чтобы распознавать этот адрес.

Для любого эникастного адреса существует адресный префикс P, который определяет топологическую область, где находятся все соответствующие ему интерфейсы. В пределах области, заданной P, каждый член эникастной (anycast) группы должен быть объявлен, как отдельный вход в маршрутной системе; вне области, заданной P, эникастный адрес может быть занесен в маршрутную запись для префикса p.

Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная единица (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких "глобальных" эникастных адресов не может быть большим.

Одним ожидаемым приложением эникастных адресов является идентификация набора маршрутизаторов, принадлежащих Интернет сервис провайдеру. Такие адреса в маршрутном заголовке IPv6 могут использоваться в качестве промежуточных, чтобы обеспечить доставку пакета через определенного провайдера или последовательность провайдеров. Другим возможным приложением может стать идентификация набора маршрутизаторов, связанных с определенной субсетью, или набора маршрутизаторов, обеспечивающих доступ в определенный домен.

Существует ограниченный опыт широкого применения эникастных Интернет адресов, некоторые возможные осложнения и трудности рассмотрены в [anycst]. Имеются следующие ограничения при использовании эникастных IPv6 адресов:

Эникастный адрес не может использоваться в качестве адреса отправителя в ipv6 пакете.

Эникастный адрес не может быть приписан ЭВМ IPv6, таким образом, он может принадлежать только маршрутизатору.

4.11.1. Необходимые эникаст-адреса

Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.4.1.1.12:

Рис. 4.4.1.1.12

Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса равным нулю.

Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым.

Эникастный адрес маршрутизатора субсети предполагается использовать в приложениях, где необходимо взаимодействовать с одним из совокупности маршрутизаторов удаленной субсети. Например, когда мобильный хост хочет взаимодействовать с одним мобильным агентом в его “домашней” субсети.

4.12. Мульткаст-адреса

Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг групп. Мультикастинг-адреса имеют следующий формат (рис. 4.4.1.1.13):

Рис. 4.4.1.1.13

11111111 в начале адреса идентифицирует адрес, как мультикатинг-адрес.

Рис. 4.4.1.1.14

Старшие 3 флага зарезервированы и должны быть обнулены.

t = 0 указывает на то, что адрес является стандартным ("well-known") мультикастным, официально выделенным для глобального использования в Интернет.

T = 1 указывает, что данный мультикастинг-адрес присвоен временно ("transient").

Поле scope представляет собой 4- битовый код мультикастинга, предназначенный для определения предельной области действия мультикастинг-группы. Допустимые значения:

0 зарезервировано

1 Область действия ограничена локальным узлом

2 Область действия ограничена локальным каналом

3 (не определено)

4 (не определено)

5 Область действия ограничена локальной сетью

6 (не определено)

7 (не определено)

8 Область действия ограничена локальной организацией

9 (не определено)

A (не определено)

B (не определено)

C (не определено)

D (не определено)

E глобальные пределы (global scope)

F зарезервировано

Идентификатор группы идентифицирует мультикастинг-группы, постоянной или переходной (transient), в пределах заданных ограничений (scope).

Значение постоянно присвоенного мультикастинг-адреса не зависит от значения поля scope. Например, если "NTP servers group" присвоен постоянный мультикастинг адрес с идентификатором группы 43 (hex), тогда:

ff01:0:0:0:0:0:0:43 означает, что все ntp серверы одного и того же узла рассматриваются как отправители.

FF02:0:0:0:0:0:0:43 означает, что все NTP серверы работают с тем же каналом, что и отправитель.

FF05:0:0:0:0:0:0:43 означает, что все NTP серверы принадлежат той же сети, что и отправитель.

FF0E:0:0:0:0:0:0:43 означает, что все NTP серверы находятся в Интернет.

Непостоянно выделенные мультикаст-адреса имеют значение только в пределах данного ограничения (scope). Например, группа, определенная непостоянным локальным мультикаст-адресом FF15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локальной сети или непостоянной группы, использующей тот же групповой идентификатор с другим scope, или для постоянной группы с тем же групповым ID.

Мультикастинг адреса не должны использоваться в качестве адреса отправителя в IPv6 дейтограммах или встречаться в любых заголовках маршрутизации.

4.12.1. Предопределенные мультикаст-адреса

Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):

ff00:0:0:0:0:0:0:0

FF01:0:0:0:0:0:0:0

FF02:0:0:0:0:0:0:0

FF03:0:0:0:0:0:0:0

FF04:0:0:0:0:0:0:0

FF05:0:0:0:0:0:0:0

FF06:0:0:0:0:0:0:0

FF07:0:0:0:0:0:0:0

FF08:0:0:0:0:0:0:0

FF09:0:0:0:0:0:0:0

FF0A:0:0:0:0:0:0:0

FF0B:0:0:0:0:0:0:0

FF0C:0:0:0:0:0:0:0

FF0D:0:0:0:0:0:0:0

FF0E:0:0:0:0:0:0:0

FF0F:0:0:0:0:0:0:0

Перечисленные выше мультикаст-адреса зарезервированы и не будут присваиваться каким-либо мультикаст-группам.

Адреса для обращения ко всем узлам:

FF01:0:0:0:0:0:0:1

FF02:0:0:0:0:0:0:1

Приведенные выше адреса идентифицируют группу, включающую в себя все IPv6 узлы в пределах группы 1 (локальные узлы) или 2 (локально связанные узлы).

Адреса всех маршрутизаторов:

FF01:0:0:0:0:0:0:2

FF02:0:0:0:0:0:0:2

Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы).

DHCP server/relay-agent: FF02:0:0:0:0:0:0:C

Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал).

Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx

Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал:

ff02:0:0:0:0:1:0000:0000

до

FF02:0:0:0:0:1:FFFF:FFFF

Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.

4.13. Необходимые адреса узлов

ЭВМ должна распознавать следующие адреса, как обращенные к нему:

Её локальный адрес канала для каждого из интерфейсов

Выделенные уникаст-адреса

Адрес обратной связи

Мультикастинг-адрес для обращения ко всем узлам

Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов

Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.

Маршрутизатор должен распознавать следующие адреса (as identifying itself):

Его локальный адрес канала для каждого из интерфейсов

Выделенные уникаст-адреса

Адрес обратной связи

Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.

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

Мультикастинг-адрес для обращения ко всем узлам

Мультикастинг-адрес для обращения ко всем маршрутизаторам

Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.

Мультикастные адреса всех прочих групп, принадлежащих маршрутизатору.

Приложение должно предопределить только следующие адресные префиксы:

Не специфицированный адрес

Адрес обратной связи

Мультикаст-префикс (ff)

Локально используемые префиксы (link-local и site-local)

Предопределенные мультикаст-адреса

Префиксы, совместимые с IPv4

Приложения должны считать все остальные адреса уникастными, если противоположное не оговорено при конфигурации (например, эникастные адреса).

5. Заголовки расширения IPv6

В IPv6, опционная информация уровня Интернет записывается в отдельных заголовках, которые могут быть помещены между IPv6 заголовком и заголовком верхнего уровня пакета. Существует небольшое число таких заголовков, каждый задается определенным значением кода поля следующий заголовок. В настоящее время определены заголовки: маршрутизации, фрагментации, аутентификации, инкапсуляции, опций hop-by-hop, места назначения и отсутствия следующего заголовка. Как показано в примерах ниже, IPv6 пакет может нести нуль, один, или более заголовков расширения, каждый задается предыдущим полем следующий заголовок (рис. 4.4.1.1.15):

Рис. 4.4.1.1.15. Структура вложения пакетов для IPv6

Заголовки расширения не рассматриваются и не обрабатываются узлами по пути доставки. Содержимое и семантика каждого заголовка расширения определяет, следует или нет обрабатывать следующий заголовок. Следовательно, заголовки расширения должны обрабатываться строго в порядке их выкладки в пакете. Получатель, например, не должен просматривать пакет, искать определенный тип заголовка расширения и обрабатывать его до обработки предыдущих заголовков.

Единственное исключение из этого правила касается заголовка опций hop-by-hop, несущего в себе информацию, которая должна быть рассмотрена и обработана каждым узлом по пути доставки, включая отправителя и получателя. Заголовок опций hop-by-hop, если он присутствует, должен следовать непосредственно сразу после IPv6-заголовка. Его присутствие отмечается записью нуля в поле следующий заголовок заголовка IPv6.

Если в результате обработки заголовка узлу необходимо перейти к следующему заголовку, а код поля следующий заголовок не распознается, необходимо игнорировать данный пакет и послать соответствующее сообщение ICMP (parameter problem message) отправителю пакета. Это сообщение должно содержать код ICMP = 2 ("unrecognized next header type encountered " - встретился нераспознаваемый тип следующего заголовка) и поле - указатель на не узнанное поле в пакете. Аналогичные действия следует предпринять, если узел встретил код следующего заголовка равный нулю в заголовке, отличном от IPv6-заголовка.

Каждый заголовок расширения имеет длину кратную 8 октетам. Многооктетные поля в заголовке расширения выравниваются в соответствии с их естественными границами, т.е., поля с шириной в n октетов помещаются в n октетов, начиная с начала заголовка, для n = 1, 2, 4 или 8.

IPv6 включает в себя следующие заголовки расширения:

Опции hop-by-hop

Маршрутизация (routing;тип 0)

Фрагмент

Опции места назначения

Проверка прав доступа (authentication)

Поле безопасных вложений (encapsulating security payload)

Последние два описаны в RFC-1826 и RFC-1827.

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

Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке:

IPv6 заголовок

Заголовок опций hop-by-hop

Заголовок опций места назначения (destination options header, (1) )

Заголовок маршрутизации

Заголовок фрагмента

Заголовок authentication (2)

Заголовок безопасных вложений (encapsulating security payload, (2) )

Заголовок опций места назначения (destination options header (3) )

Заголовок верхнего уровня.

(1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации.

(2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827.

(3) для опций, которые должны обрабатываться при достижении пакетом конечной точки маршрута.

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

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

Узлы IPv6 должны принимать и пытаться обработать заголовки расширения в любом порядке, встречающиеся любое число раз в пределах одного пакета, за исключением заголовка опций типа hop-by-hop, который может появляться только непосредственно за IPv6 заголовком.

6. Опции

Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (Рис. 4.4.1.1.16):

Рис. 4.4.1.1.16 Формат опций

Тип опции	8-битовый идентификатор типа опции.
Длина опции	8-битовое целое число без знака. Длина поля данных опции в октетах.
Данные опции	Поле переменной длины. Данные зависят от типа опции.

<

/p> Последовательность опций в заголовке должна обрабатываться строго в соответствии с их порядком записи.

Идентификаторы типа опций кодируются так, что их старшие два бита характеризуют операцию, которая должна быть выполнена, если узел не узнает тип опции:

00	обойти эту опцию и продолжить обработку заголовка.
01	выбросить данный пакет.
10	выбросить данный пакет и вне зависимости от того, является ли адрес назначения мультикастинговым, послать отправителю ICMP-пакет с кодом parameter problem (код=2), с указателем на не узнанный код опции.
11	выбросить данный пакет и, если адрес места назначения не мультикастинговый, послать отправителю icmpпакет с кодом parameter problem (код=2) с указателем на не узнанный код опции.

Третий старший бит типа опции определяет, может ли информация в поле опция измениться по пути до места назначения пакета. Когда в пакете присутствует заголовок аутентификации, для любой опции, информация которой может измениться по пути, должна рассматриваться как нулевые октеты при определении значения идентификации. Значения этого бита:

0 - Данные опции не меняют маршрута

1 - Информация опции может изменить маршрут.

Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:

2n	означает любое двухоктетное смещение от начала заголовка.
8n+2	означает любое 8-октетное смещение от начала заголовка плюс 2 октета.

Существует две опции заполнения, которые используются, когда необходимо выровнять последующие опции и вывести границу заголовка на значение кратное 8 октетам. Эти заполняющие опции должны распознаваться всеми приложениями IPv6:

Опция Pad1 (выравнивание не требуется)

Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn.

Опция padn (выравнивание не требуется)

Рис. 4.4.1.1.17

Опция Padn используется для введения двух и более октетов заполнителей в поле опций заголовка. Для n октетов заполнителя поле OPT data Len содержит значение n-2, а поле данных опции состоит из n-2 нулевых октетов

6.1. Опции заголовка Hop-by-Hop (шаг за шагом)

Заголовок опций hop-by-hop (шаг за шагом) используется для опционной информации, которая просматривается каждым узлом по пути доставки. Заголовок опций hop-by-hop идентифицируется кодом поля следующий заголовок 0 в IPv6 заголовке и имеет формат (рис. 4.4.1.1.18):

Рис. 4.4.1.1.18. Формат заголовка опций hop-by-hop

Следующий заголовок	8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком опций hop-by-hop. Использует те же значения поля протоколов, что и IPv4 [RFC-1700]
HDR EXT LEN	8-битовое число без знака. Длина заголовка поля опций hop-by-hop в октетах, исключая первые 8 октетов.
Опции	Поле переменной длины. Содержит один или более TLV-закодированных опций.

В дополнение к Pad1 и Padn опциям определены следующие опции hop-by-hop:

Опция Jumbo Payload

(необходимо выравнивание: 4n + 2)

Рис. 4.4.1.1.19.

Опция Jumbo payload используется для посылки пакетов IPv6 с полем данных, превосходящим 65535 октетов. Длина Jumbo Payload характеризует длину пакета в октетах, исключая заголовок IPv6, но включая заголовок опций hop-by-hop; Это поле должно содержать код более чем 65535. Если получен пакет с опцией Jumbo payload, содержащей код длины меньше или равный 65535, посылается сообщение ICMP (parameter problem, код 0) с указателем на старший октет поля длины Jumbo payload.

Поле длины Payload length IPv6 заголовка должно быть равно нулю для каждого пакета с опцией Jumbo payload. Если получен пакет с корректным значением опции Jumbo Payload и ненулевым кодом длины поля данных, посылается сообщение ICMP (parameter problem код 0) с указателем на поле тип опции.

Опция Jumbo payload не может использоваться в пакетах, которые несут в себе заголовок фрагмента. Если заголовок фрагмента встретится в пакете, содержащем корректную опцию jumbo payload, посылается сообщение ICMP (parameter problem, код 0) с указателем на первый октет заголовка фрагмента.

Приложения, которые не поддерживают опцию Jumbo Payload, не могут иметь интерфейсы для каналов с MTU больше 65575 (40 октетов IPv6 заголовка плюс 65535 октетов данных).

7. Маршрутный заголовок

Заголовок маршрутизации используется отправителем, чтобы заставить пакет посетить один или более промежуточных узлов на пути к месту назначения. Эта функция схожа с опцией принудительной маршрутизации в протоколе IPv4. Заголовок маршрутизации идентифицируется кодом 43 поля следующий заголовок предыдущего заголовка и имеет формат:

Следующий заголовок	8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].
hdr ext len	8-битовое целое без знака. Длина заголовка маршрутизации выражается в 8-октетных блоках, и не включает в себя первые 8 октетов.
Тип маршрутизации	8-битовый идентификатор конкретного варианта маршрутизации
Оставшиеся сегменты	8-битовое число без знака. Число остающихся сегментов пути, т.e. число промежуточных узлов, которые должны быть посещены пакетом по пути к месту назначения.
Данные, зависящие от типа	Поле переменной длины, формат зависит от кода поля тип маршрутизации, а длина определяется заголовком маршрутизации и кратна 8 октетам.

Если в процессе обработки входного пакета встретится заголовок маршрутизации с не узнанным полем тип маршрутизации, то поведение узла зависит от содержимого поля число оставшихся сегментов пути.

Если число оставшихся сегментов пути равно нулю, узел должен проигнорировать заголовок маршрутизации и продолжить работу со следующим заголовком, чей тип указан в поле следующий заголовок заголовка маршрутизации.

Если число оставшихся сегментов пути не равно нулю, узел должен выбросить пакет и послать сообщение ICMP (parameter problem, код 0) с указателем на поле не узнанного типа маршрутизации. Заголовок маршрутизации типа 0 имеет следующий формат (рис. 4.4.1.1.20):

Рис. 4.4.1.1.20. Формат заголовка маршрутизации типа 0

Следующий заголовок	8-битовый селектор. Идентифицирует тип заголовка, следующего непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].
hdr ext len	8-битовое целое без знака. Длина заголовка маршрутизации в 8-октетных блоках, исключая первые 8 октетов. Для заголовков маршрутизации типа 0 hdr ext len равна удвоенному числу адресов в заголовке, должно быть четным числом меньше или равным 46.
Тип маршрутизации	0.
Оставшиеся сегменты	8-битовое целое без знака. Число оставшихся сегментов пути, т.e., число узлов, которые следует посетить на пути к месту назначения. Максимально допустимое число = 23
Резерв	8-битовое поле резерва. Инициализируется нулем при передаче и игнорируется при приеме.
strict/loose bit map	24-битовый код-маска, биты пронумерованы, начиная с 0 до 23, слева направо. Для каждого из сегментов пути указывает должен ли следующий узел быть соседом: 1 означает strict (должен быть соседом), 0 означает пропустить (не должен быть соседом).
Адрес[1..n]	Вектор 128-битовых адресов, пронумерованных с 1 до n.

<

/p> Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 0, или в поле места назначения IPv6 пакета, несущего в себе заголовок маршрутизации типа 0.

Если бит 0 поля Strict/loose bit map имеет значение 1, поле адреса места назначения IPv6 заголовка в исходном пакете должно идентифицировать соседа. Если бит 0 имеет значение 0, отправитель может использовать любой легальный не мультикастинговый адрес в качестве адреса места назначения.

Биты с номерами более n, где n - число адресов в заголовке маршрутизации, должны быть обнуляться отправителем и игнорироваться получателем.

Заголовок маршрутизации не рассматривается и не анализируется до тех пор, пока пакет не достигнет места назначения, указанного в поле IPv6 заголовка. Узел, указанный в поле следующий заголовок заголовка, которому принадлежит модуль заголовка маршрутизации, реализует следующий алгоритм:

Если оставшееся число сегментов = 0

{ продолжить обработку следующего заголовка пакета, чей тип задан полем следующий заголовок заголовка маршрутизации }

else если HDR ext len является нечетным или больше 46,

{посылается сообщение ICMP (parameter problem, код 0) с указателем на поле HDR #EXT LEN, пакет выбрасывается}

else

{ вычислить n, число адресов в заголовке маршрутизации, для этого код HRD EXT LEN делится на 2

Если число оставшихся сегментов пути больше n,

{послать сообщение ICMP (parameter problem, код 0) с указанием на поле числа оставшихся сегментов пути }

else

{ уменьшить число оставшихся сегментов пути на 1;

Вычислить i, индекс следующего адреса, который следует посетить, для этого вычесть число оставшихся сегментов пути из n

Если адрес [i] или адрес места назначения IPv6 являются мультикастинговыми

{ выбросить пакет }

else { поменять местами адрес места назначения IPv6 и адрес[i]

если бит i поля strict/loose bit map имеет значение 1 и новый адрес места назначения не является адресом узла соседа

{ послать сообщение ICMP destination unreachable -- not a neighbor

и выбросить пакет }

else если код IPv6 hop limit меньше или равен 1

{послать сообщение icmp time exceeded -- hop limit exceeded in transit message и выбросить пакет }

else { уменьшить hop limit на 1

повторно направить пакет модулю IPv6 для отправки новому адресату }

}

}

}

В качестве примера работы приведенного выше алгоритма, рассмотрим случай, когда узел отправителя s посылает пакет получателю D, используя заголовок маршрутизации, чтобы заставить пакет пройти через промежуточные узлы I1, I2 и I3. Значения кодов полей заголовка IPv6 и заголовка маршрутизации для каждого из сегментов пути принимают следующие значения:

При движении пакетов от S к I1:

Адрес отправителя = S	Hdr Ext Len = 6
Адрес получателя = I1	Число оставшихся сегментов пути = 3
Адрес[1] = I2
Если бит 0 bit map равен 1, s и i1 должны быть соседями; это проверяется узлом S	Адрес[2] = I3 Адрес[3] = d

При движении пакетов от I1 к I2:

Адрес отправителя = s	Hdr Ext Len = 6
Адрес получателя = I2	Число оставшихся сегментов пути = 2
Адрес[1] = I1
Если бит 1 bit map равен 1, I1 и I2 должны быть соседями; это проверяется узлом I1	Адрес[2] = i3 Адрес[3] = D

При движении пакетов от I2 к I3:

Адрес отправителя = S	Hdr Ext Len = 6
Адрес получателя = I3	Число оставшихся сегментов пути = 1 Адрес[1] = I1
Если бит 2 bit map равен 1, I2 и I3 должны быть соседями; это проверяется узлом I2	Адрес[2] = I2
Адрес[3] = D

При движении пакетов от I3 к D:

Адрес отправителя = S	Hdr Ext Len = 6
Адрес получателя = D	Число оставшихся сегментов пути = 0 Адрес[1] = I1
Если бит 3 bit map равен 1, I3 и D должны быть соседями; это проверяется узлом I3	Адрес[2] = I2 Адрес[3] = i3

8. Заголовок фрагмента

Заголовок фрагмента используется отправителем IPv6 для посылки пакетов длиннее, чем MTU пути до места назначения. (Замечание: в отличие от IPv4, фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами вдоль пути доставки). Заголовок фрагментации идентифицируется кодом поля следующий заголовок, равным 44 и имеет следующий формат (рис. 4.4.1.1.21):

Рис. 4.4.1.1.21. Формат заголовка фрагментации

Следующий заголовок	8- битовый селектор. Идентифицирует тип исходного заголовка фрагментируемой части исходного пакета. Использует те же коды протоколов, что и IPv4 [RFC-1700].
Резерв	8-битовое резервное поле. Инициализируется нулем при передаче и игнорируется при приеме.
Fragment offset	13-битовое число без знака. Смещение в 8-октетном блоке, для данных, которые следуют за этим заголовком, началом отсчета является начало фрагментируемой части исходного пакета.
Резерв (второй)	2-битовое резервное поле. Инициализируется нулем при передаче и игнорируется при приеме.
m флаг	1 = есть еще фрагменты; 0 = последний фрагмент.
Идентификация	32 бита

Для того чтобы послать пакет с длиной больше MTU пути, узел-отправитель может разделить пакет на фрагменты и послать каждый фрагмент в виде отдельного пакета, сборка исходного пакета будет проведена получателем.

Для каждого пакета, который должен быть фрагментирован, узел-отправитель генерирует код идентификации. Этот код должен отличаться от аналогичных кодов идентификации, используемых для других фрагментируемых пакетов, которые пересылаются в данный момент. Под "данным моментом" подразумевается период времени жизни пакета, включая время распространения кадра от источника до получателя и время, необходимое для сборки исходного (оригинального) пакета получателем. Однако не предполагается, чтобы отправитель знал максимальное время жизни пакета. Скорее предполагается, что данное требование будет удовлетворено с помощью простого 32-разрядного счетчика, инкрементируемого всякий раз, когда очередной пакет должен быть фрагментирован. Схема реализации генератора кода идентификации оставляется на усмотрение приложения. Если присутствует заголовок маршрутизации, под адресом получателя подразумевается конечное место назначения.

Под исходным большим, не фрагментированным пакетом подразумевается “оригинальный” пакет. Предполагается, что он состоит из двух частей, как показано на рисунке 4.4.1.1.22:

Исходный пакет:

Рис. 4.4.1.1.22.

Не фрагментированная часть состоит из IPv6 заголовка плюс любых заголовков расширения, которые должны быть обработаны узлами по пути до места назначения. Таким образом, нефрагментированная часть включает в себя все заголовки вплоть до заголовка маршрутизации, если таковой присутствует, или до заголовка опций hop-by-hop, если он присутствует.

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

Фрагментируемая часть оригинального пакета делится на фрагменты с длиной кратной 8 октетам. Фрагменты пересылаются независимо с помощью пакетов-фрагментов. Как показано на рис. Рис. 4.4.1.1.23

Исходный пакет:

Пакеты-фрагменты:

o

o

o

Рис. 4.4.1.1.23.

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

(1) Не фрагментируемой части оригинального пакета, с длиной поля данных оригинального IPv6 заголовка, измененной для того чтобы соответствовать длине фрагмента пакета (исключая длину самого IPv6-заголовка), а код поля следующий заголовок последнего заголовка не фрагментируемой части меняется на 44.

(2) Заголовка фрагмента, включающего в себя:

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

Смещение фрагмента, выражаемое в 8-октетных блоках и отсчитываемое от начала фрагментируемой части оригинального пакета. Смещение первого фрагмента (самого левого) равно нулю.

Код M-флага равен нулю, если фрагмент является последним (самым правым), в противном случае флаг равен 1.

(3) Сам фрагмент.

Длина фрагментов должна выбираться такой, чтобы пакеты-фрагменты соответствовали значению MTU для маршрута к месту назначения (назначений). В узле места назначения из пакетов-фрагментов восстанавливается оригинальный пакет в не фрагментированной форме.

Восстановленный оригинальный пакет:

Рис. 4.4.1.1.24.

В процессе восстановления должны выполняться следующие правила:

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

Не фрагментируемая часть восстанавливаемого пакета состоит из всех заголовков вплоть до (но не включая) заголовок фрагмента первого пакета-фрагмента (пакет со смещением равным нулю). При этом производятся следующие изменения:

Поле следующий заголовок последнего заголовка не фрагментируемой части берется из поля следующий заголовок заголовка первого фрагмента.

Длина поля данных восстановленного пакета вычисляется с использованием длины не фрагментируемой части, а также длины и смещения последнего фрагмента. Например, формула расчета длины поля данных восстановленного пакета имеет вид:

pl.orig = pl.first - fl.first - 8 + (8 * fo.last) + fl.last

где

pl.orig - поле длины данных восстановленного пакета.

pl.first - поле длины данных первого пакета-фрагмента.

fl.first - длина фрагмента, следующего за заголовком первого пакета-фрагмента.

fo.last - Поле смещения фрагмента в заголовке последнего пакета-фрагмента.

fl.last - длина фрагмента, следующего за заголовком фрагмента последнего пакета-фрагмента.

Фрагментируемая часть восстановленного пакета состоит из частей, следующих за заголовками в каждом из пакетов-фрагментов. Длина каждого фрагмента вычисляется путем вычитания из длины поля данных длины заголовков, размещенных между IPv6 заголовком и самим фрагментом. Их относительное положение в фрагментируемой части вычисляется на основе значения смещения фрагмента. Заголовок фрагмента отсутствует в восстановленном пакете.

В процессе сборки могут возникнуть следующие ошибки:

Если в пределах 60 секунд после прихода первого фрагмента получено недостаточно фрагментов для завершения сборки, процедура сборки должна быть прервана и все полученные фрагменты выкинуты. Если первый фрагмент (т.e., пакет с нулевым смещением) получен, посылается ICMP сообщение “Time exceeded -- Fragment reassemble time exceeded”.

Если длина фрагмента, полученная из поля длины данных пакета, не является кратным 8 октетам, а M флаг фрагмента равен 1, фрагмент должен быть выброшен и должно быть послано сообщение ICMP (parameter problem, код 0) с указателем на поле длины данных пакета-фрагмента.

Если длина и смещение фрагмента таковы, что восстановленная длина поля данных фрагмента превосходит 65,535 октетов, фрагмент выбрасывается, посылается сообщение ICMP (parameter problem, код 0) с указателем на поле смещения фрагмента пакета-фрагмента.

Следующие условия не должны реализоваться, но они также рассматриваются как ошибка, если это произойдет:

Число и содержимое заголовков, предшествующих заголовку фрагмента, отличаются для разных фрагментов одного и того же исходного пакета. Какие бы заголовки ни предшествовали, заголовку фрагмента, они обрабатываются по прибытии на место назначения до постановки фрагментов в очередь на восстановление. Только эти заголовки из пакета с нулевым смещением сохраняются в восстановленном пакете.

Значение поля следующий заголовок в заголовках фрагментов различных фрагментов исходного пакета могут отличаться. Для последующей сборки используется только значение из пакета-фрагмента с нулевым смещением.

9. Заголовок опций места назначения

Заголовок опции места назначения используется для передачи опционной информации, которая должна анализироваться только узлом (узлами) назначения. Заголовок опции места назначения идентифицируется кодом поля следующий заголовок равным 60 предшествующего заголовка и имеет формат (рис. 4.4.1.1.25):

Рис. 4.4.1.1.25. Формат заголовка опции места назначения

Следующий заголовок - 8-битовый селектор. Идентифицирует тип заголовка, который непосредственно следует за заголовком опций места назначения. Использует те же коды протокола, что и IPv4 [RFC-1700].

Hdr Ext Len - 8-битовое целое без знака. Длина заголовка опций места назначения в 8-октетных блоках, исключая первые 8 октетов.

Опции - поле переменной длины, кратное 8 октетам. Содержит одну или более TLV-закодированных опций.

Здесь определены только две опции места назначения Pad1 и padn. Обратите внимание, что существует два способа кодировки опционной информации места назначения для пакетов IPv6: в заголовке опций места назначения, или в виде отдельного заголовка расширения. Заголовок фрагмента и заголовок идентификации являются примерами последнего подхода. Какой из подходов будет применен, зависит от того, какая операция желательна в узле места назначения:

если желательно, чтобы узел назначения уничтожил пакет и, если адрес места назначения не является мультикастинговым, отправителю посылается сообщение ICMP unrecognized type, затем информация может быть закодирована в отдельном заголовке или в опции места назначения с кодом типа опции, равным 11 в старших двух битах. Выбор может зависеть от таких факторов как число необходимых октетов, проблема выравнивания или более простой анализ пакета.

если желательна какая-либо иная операция, информация должна быть закодирована в виде опции места назначения с типом опции 00, 01 или 10 в старших двух битах.

10. Отсутствие следующего заголовка

Код 59 в поле следующий заголовок IPv6 заголовка или любой другой заголовок расширения указывает, что за этим заголовком ничего не следует. Если поле длина данных заголовка IPv6 указывает на присутствие октетов после конца заголовка, содержащего код 59 в поле следующий заголовок, эти октеты должны быть проигнорированы и переданы без изменений при переадресации пакета.

11. О размере пакетов

Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.

Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery.

Для того чтобы послать пакет длиннее чем MTU канала, узел может использовать заголовок фрагментации IPv6. Однако использование такой фрагментации заблокировано в приложениях, где используется настройка по измеренному значению MTU пути.

Узел должен быть способен принимать фрагментированные пакеты, которые после сборки имеют размер 1500 октетов, включая IPv6 заголовок. Узлу позволено принимать пакеты, которые после сборки имеют размер более 1500 октетов. Однако узел не должен посылать фрагменты, которые после сборки образуют пакеты длиннее 1500 октетов, если он не уверен, что получатель способен их воспринять и дефрагментировать.

В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.

Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел “думает”, что адресат находится на том же канале что и сам узел.

Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.

12. Метки потоков

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.

Поток это последовательность пакетов, посылаемых отправителем определенному адресату, при этом предполагается, что все пакеты данного потока должны быть подвергнуты определенной обработке. Характер этой специальной обработки может быть передан маршрутизатору посредством протокола управления или внутри самих пакетов, например, в опции hop-by-hop.

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

Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - ffffff. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку.

Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).

Маршрутизаторы могут произвольно варьировать способ обработки потоков данных, даже когда имеется какая-либо информация о потоке со стороны протокола управления, опции hop-by-hop или другого источника. Например, при получении пакетов от какого-то источника с неизвестной ненулевой меткой, маршрутизатор может обрабатывать их IPv6-заголовок и любой необходимый заголовок расширения так, как если бы метка равнялась нулю. Такая обработка может включать выявление интерфейса следующего шага и другие действия, такие как актуализация опции hop-by-hop, перемещение указателя и адресов в заголовке маршрутизации и т.д.. Маршрутизатор может запомнить результаты такой обработки, занеся их в кэш (адрес отправителя и метка образуют ключ кэша). Последующие пакеты с тем же адресом отправителя и меткой потока могут обрабатываться с использованием информации из кэша без детального просмотра всех полей, которые, согласно уже описанному, должны быть идентичными.

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

Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или опцию hop-by-hop, и может превышать 6 секунд.

Отправитель не должен использовать старую метку для нового потока в пределах времени жизни любого потока. Так как режим обработки потока на 6 секунд может быть установлен для любого потока, минимальный интервал между последним пакетом одного потока и первым пакетом нового, использующего ту же метку, должно быть равно 6 секундам. Метки потока, которые используются для потоков, существующих более продолжительное время не должны использоваться соответственно дольше.

Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков.

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

13. Приоритет

4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов “реального времени”, посылаемых с постоянной частотой.

Для трафика, управляемого сигналами перегрузки, рекомендуются следующие значения приоритета для конкретных категорий приложений (см. таблицу 4.4.1.1.2).

Таблица 4.4.1.1.2. Значения кодов приоритета

Код приоритета	Назначение
0	Нехарактеризованный трафик
1	Заполняющий трафик (например, сетевые новости)
2	Несущественный информационный трафик (например, электронная почта)
3	Резерв
4	Существенный трафик (напр., FTP, HTTP, NFS)
5	Резерв
6	Интерактивный трафик (напр. telnet, x)
7	Управляющий трафик Интернет (напр., маршрутные протоколы, snmp)

Предполагается, что чем больше код, тем выше приоритет данных, тем быстрее они должны быть доставлены. Так для передачи мультимедийной информации, где управление скоростью передачи не возможно, уровень приоритета должен лежать в пределах 8-15. Практически, уровни приоритета выше или равные 8 зарезервированы для передачи данных в реальном масштабе времени.

Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видео трафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (напр., аудио трафик с низкой надежностью). Не существует связи между относительными приоритетами обменов с и без контроля перегрузки.

14. О протоколе верхнего уровня

14.1 Контрольные суммы верхнего уровня

Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):

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

Если пакет содержит заголовок маршрутизации, в качестве адреса места назначения в псевдо-заголовке используется оконечный адрес. В исходном узле этот адрес будет последним элементом заголовка маршрутизации; для узла получателя он будет находиться в поле адрес места назначения IPv6 заголовка.

Код поля следующий заголовок в псевдо- заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.

В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.

В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на ffff для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.

IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.

15. Максимальное время жизни пакета

В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение.

16. Максимальный размер поля данных для протоколов высокого уровня

При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.

17. Приложение a. Рекомендации по формированию опций

Это приложение дает некоторые советы, как выкладывать поля, при формировании новых опций, предназначенных для использования в заголовке опций hop-by-hop или в заголовке опций места назначения. Эти рекомендации базируются на следующих предположениях:

Желательно, чтобы любые многооктетные поля в пределах данных опции были выровнены на их естественные границы, т.e., поля с длиной в n октетов следует помещать со смещением по отношению к началу заголовка (hop-by-hop или destination options), кратным n октетам, для n = 1, 2, 4 или 8.

Другим желательным требованием является минимальное место, занимаемое hop-by-hop или опциями места назначения, а длина заголовка должна быть кратной 8 октетам.

Можно предположить, что когда присутствует какой-то заголовок, содержащий опции, он несет в себе небольшое число опций, обычно одну.

Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения. Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах:

Пример 1

Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (рис. 4.4.1.1.27):

Рис. 4.4.1.1.27.

Требование выравнивания соответствует 8n+2, для того чтобы гарантировать начало 8-октетного поля со смещением, кратным 8, от начала последнего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из этих опций будет иметь формат (рис. 4.4.1.1.28):

Рис. 4.4.1.1.28

Пример 2

Если опция y требует трех полей данных, одно длиной 4 октета, одно - 2 октета и одно - длиной один октет, она будет уложена следующим образом (рис. 4.4.1.1.29):

Рис. 4.4.1.1.29

Требование выравнивания выглядит как 4n+3, и призвано гарантировать, что 4-октетное поле начнется со смещением кратным 4 по отношению к началу завершающего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из указанных опций будет иметь вид (рис. 4.4.1.1.30):

Рис. 4.4.1.1.30

Пример 3

Заголовок с опциями hop-by-hop или destination options, содержащий обе опции x и y из примеров 1 и 2, будет иметь один из приведенных ниже форматов, в зависимости от того, какая из опций встречается первой (рис. 4.4.1.1.31, 4.4.1.1.32):

Рис. 4.4.1.1.31

Рис. 4.4.1.1.32

18. Соображения безопасности

Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825].

19. Расширение DNS для поддержки IP-версии 6 (DNS Extensions to Support IP Version 6. S. Thomson. RFC-1886)

Существующая поддержка записи адресов Интернет в DNS (Domain Name System) [1,2] не может быть легко расширена для поддержки IPv6-адресов [3], так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес.

Для того чтобы запоминать IPv6-адреса, определены следующие расширения:

Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6.

Определен новый домен, предназначенный для обработки запросов по новым адресам.

Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов.

Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние осуществования IPv4 и IPv6-адресов обсуждается в [4].

19.1. Определение новой ресурсной записи и домена

Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.

Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).

128-битовый IPv6-адрес записывается в информационной части ресурсной записи aaaa, придерживаясь порядка байт, используемого в сети (старший байт первый).

Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции aaaa. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции.

Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.

Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.

IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу

4321:0:1:2:3:4:567:89ab

будет выглядеть как

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.

19.2. Модификации существующих типов запроса

Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа aaaa должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально.

20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6 (a. conta. internet control message protocol (ICMPv6) for the internet protocol version 6 (IPv6) specification. RFC-1885)

Протокол IPv6 является новой версией IP. IPv6использует протокол управляющих сообщений (ICMP) так, как это определено для IPv4 [RFC-792], но с некоторым количеством изменений. Протокол подключения к группам (IGMP), специфицированный для IPv4 [RFC-1112] был также пересмотрен и включен в протокол ICMP для IPv6. Результирующий протокол называется ICMPv6, и имеет код следующего заголовка 58.

20.1. ICMPv6 (ICMP для IPv6)

ICMPv6 используется узлами IPv6 для сообщений об ошибках при обработке пакетов, и для выполнения других функций уровня Интернет, таких как диагностика (ICMPv6 "ping") и сообщение об участии в мультикастинг группах. Протокол ICMPv6 является интегрированной частью IPv6 и должен реализовываться каждым узлом, поддерживающим IPv6.

20.2. Общий формат сообщений

Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите поля тип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255.

В данном документе определены форматы для следующих сообщений ICMPv6:

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

1 destination unreachable (место назначения недоступно)

2 packet too big (пакет слишком велик)

3 time exceeded (время превышено)

4 parameter problem (проблема с параметрами)

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

128 echo request (Запрос эхо)

129 echo reply (Эхо-отклик)

130 group membership query (запрос участия в группе)

131 group membership report (отчет об участии в группе)

132 group membership reduction (сокращение числа участников в группе)

Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.)

Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):

Рис. 4.4.1.1.33. Общий формат сообщений ICMPv6

Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных.

Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.

Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:

Если сообщение является откликом на сообщение, полученное по одному из уникаст адресов, адресом отправителя должен стать именно этот адрес.

Если сообщение является откликом на мультикаст- или эникаст-сообщение группе, в которую входит данный узел, адресом отправителя должен стать никастный адрес интерфейса, откуда пришло сообщение-первопричина отклика.

Если сообщение является откликом на сообщение, посланное по адресу, который не принадлежит данному узлу, в качестве адреса отправителя следует выбрать уникаст адрес, принадлежащий узлу и обещающий наибольшую диагностическую полезность. Например, если сообщение является откликом на операцию переадресации пакета, которая не может быть завершена успешно, в качестве адреса отправителя должен быть взят уникаст-адрес интерфейса, переадресация на который не удалась.

В противном случае, должна быть просмотрена таблица маршрутизации узла и выяснено, какой интерфейс должен быть использован для достижения места назначения сообщения. Уникастный адрес этого интерфейса и должен быть выбран в качестве адреса отправителя.

Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.

Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):

Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.

Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.

Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.

В тех случаях, когда протокол интернет-уровня нуждается в передаче сообщения об ошибке ICMPv6 вышерасположенному уровню, тип протокола верхнего уровня извлекается из исходного пакета (содержащегося в теле сообщения об ошибке ICMPv6) и используется для выбора соответствующего протокола верхнего уровня при последующей обработке сообщения об ошибке.

Если исходный пакет имеет необычно большое число заголовков расширения, возможно, что тип протокола верхнего уровня может отсутствовать в сообщении ICMPv6, из-за укорочения исходного пакета до уровня 576 октетов. В этом случае сообщение об ошибке отбрасывается после обработки уровня IPv6.

Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:

(e.1) сообщения об ошибке ICMPv6, или

(e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) – чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или

(e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес.

(f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала.

Существует много способов ограничения частоты посылки сообщений, например:

(f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.

(f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.

Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).

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

Рис. 4.4.1.1.34. Формат сообщения о недостижимости адресата

Поля IPv6:

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

Поля ICMPv6:

Тип = 1

Код = 0 – нет маршрута до места назначения

1 – связь с адресатом административно запрещена

2 – не сосед

3 – адрес не достижим

4 – порт не достижим

Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.

Описание

Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки).

Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию).

Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1.

Если причиной потери пакета является то, что следующий узел в маршрутной таблице не является соседом данного узла, то поле код принимает значение 2.

Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3.

Узел места назначения может посылать сообщение “адресат не достижим” с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет.

Узел, получивший сообщение ICMPv6 “ адресат не достижим” должен уведомить об этом протокол вышележащего уровня.

Рис. 4.4.1.1.35. Сообщение packet too big (пакет слишком велик)

Поля IPv6:

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

Поля ICMPv6:

Тип 2

Код 0

mtu mtu следующего шага.

Описание

Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191].

Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня.

Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (рис. 4.4.1.1.33).

Поля ICMPv6:

Тип 3

Код 0 – при передаче превышен лимит числа шагов

1 – превышено время восстановления сообщения из фрагментов.

Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.

Описание

Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit.

Посылая сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным нулю, маршрутизатор должен рассматривать входной интерфейс, в соответствии с правилом выбора адреса отправителя (d).

Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.

Рис. 4.4.1.1.36. Сообщение о конфликте параметров

Поля ICMPv6:

Тип 4

Код 0 – встретилась ошибка в поле заголовка

1 – встретился неопознанный код поля следующий заголовок

2 – встретилась неопознанная опция IPv6

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

Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось.

Описание

Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки.

Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полем указатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка.

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

Рис. 4.4.1.1.37. Сообщение запрос эхо

Поля IPv6:

Адрес места назначения – любой легальный IPv6-адрес

Поля ICMPv6:

Тип 128

Код 0

Идентификатор. Идентификатор, который помогает друг с другом связать запрос эхо и эхо-отклик. Может равняться нулю.

Номер по порядку

Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.

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

Описание

Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.

Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5).

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.

Поля ICMPv6:

Тип 129

Код 0

Идентификатор. Идентификатор из исходного запроса эхо (echo request).

Номер по порядку. Номер по порядку из исходного запроса эхо.

Информация. Данные из исходного запроса эхо.

Описание

Каждый узел должен иметь встроенную функцию отклика ICMPv6, которая получает запросы эхо и посылает соответствующие эхо-отклики. Узел должен также реализовать интерфейс прикладного уровня для посылки запросов эхо и получения эхо-откликов для диагностических целей.

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

Эхо-отклик должен быть послан в ответ на запрос эхо, посланный по мультикастному адресу. Адрес отправителя в отклике должен быть уникастным адресом, принадлежащим интерфейсу, через который был получен мультикастный запрос эхо.

Информация, полученная в ICMPv6 сообщении запроса эхо, должна быть полостью возвращена без модификации в ICMPv6 эхо-отклике, если эхо-отклик не превысит MTU обратного прохода, в противном случае пакет укорачивается.

Оповещение верхнего уровня

Сообщения эхо-отклик должны передаваться пользовательскому интерфейсу ICMPv6, если соответствующий запрос эхо исходит не из IP-уровня.

Сообщение о членстве в группе имеет следующий формат:

Рис. 4.4.1.1.38. Сообщения участия в группе

Поля IPv6:

Адрес места назначения

В сообщении-запросе о членстве в группе запрашивается мультикаст-адрес группы.

В отчете о членстве в группе или в сообщении о сокращении членства в группе сообщается мультикаст-адрес группы.

Поле Hop Limit = 1 (предельное число шагов)

Поля ICMPv6:

Тип 130 – Запрос членства в группе

131 – Отчет о членстве в группе

132 – Сокращение членства в группе

Код 0

Максимальное время отклика

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

Не используется. Отправитель записывает нуль, получатель игнорирует.

Мультикаст-адрес

Адрес мультикаст-группы, сообщение о которой послано. В сообщениях-запросах поле мультикаст-адреса может равняться нулю, что означает запрос ко всем группам.

Описание

Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].

Литература

[1]	Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987.
[2]	Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[3]	Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.
[4]	Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress.
[ALLOC]	Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, cisco Systems, December 1995
[ANYCST]	Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, BBN, November 1993.
[CIDR]	Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.
[IPV6]	Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995.
[IPv6-ADDR]	Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.
[IPv6-DISC]	Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Work in Progress
[MULT]	Deering, S., "Host Extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989
[NSAP]	Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and TP over IPv6", Work in Progress.
[RFC-791]	Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
[RFC-792]	Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981
[RFC-1112]	Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[RFC-1122]	Braden, R., "Requirements for Internet Hosts -Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989
[RFC-1191]	Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191, DECWRL, Stanford University, November 1990.
[RFC-1661]	Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
[RFC-1700]	Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[RFC-1825]	Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.
[RFC-1826]	Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995.
[RFC-1827]	Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC 1827, Naval Research Laboratory, August 1995
[RFC-1885]	Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment Corporation, Xerox PARC, December 1995.
[RFC-1884]	Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995
[RFC-1933]	Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E. Nordmark. April 1996
[RFC-1970]	Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark & W. Simpson. August 1996.
[RFC-1971]	IPv6 Stateless Address Autoconfiguration. S. Thomson & T. Narten. August 1996.
[RFC-1972]	A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996.
[RFC-2019]	Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996.
[RFC-2030]	Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996.
[RFC-2080]	RIPng for IPv6. G. Malkin, R. Minnear. January 1997.
[RFC-2133]	Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997.

Содержание раздела