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

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

В документе RFC-2460, который появился спустя три года после RFC-1883, поле приоритет заменено на поле класс трафика. Это поле имеет 8 бит (против 4 в поле приоритет). При этом размер поля метка потока сократился до 20 бит. Это было продиктовано требованиями документа RFC-2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", ориентированного на решение задач управления QoS. RFC 2460 определило шесть расширений заголовка: hop-by-hop, маршрутизации, фрагментации, места назначения, аутентификации (AH), и инкапсулирующее поле данных безопасности (ESP). Последние два расширения относятся к протоколу безопасности IPSec. IPsec представляет собой набор протоколов для обеспечения безопасности IP-коммуникаций путем аутентификации отправителя и обеспечения целостности и опционно конфиденциальности для передаваемых данных. IPSec является обязательной составляющей при реализации IPv6. Смотри также RFC-4308 (Cryptographic Suites for IPsec). При работе с IPSec весьма полезно использовать архивацию IP-пакетов (см. RFC 3173 (IP Payload Compression (IPComp)), RFC 2394 (IP Payload Compression Using DEFLATE) и RFC 2395 (IP Payload Compression Using LZS)).

2.1. Выбор адресов

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

В системах, работающих одновременно с IPv4 и IPv6, процедура выбора адресов еще сложнее, и нужны правила, какие адреса предпочтительнее.

Выбор адресов может быть между IPv4 и IPv6, адресами с различными зонами действия (scopes), публичными и частными адресами и т.д.. Некоторые правила представляются очевидными, например, выбор адреса, использование которого не запрещено, но программа должна делать правильный выбор в любом варианте. Вообще, пары адресов отправителя и получателя должны иметь согласованные области действия и типы (scopes) (напр., местный IPv6, 6to4, или IPv4-mapped), следует предпочитать меньшие зоны действия, местные адреса и т.д. Если адрес места назначения является мультикастным, при выборе уникастного адреса отправителя используется мультикастная зона. Одним из принципов выбора адресов является использование наибольшего приемлемого префикса, это означает, что в отсутствие других критериев, следует выбирать адреса отправителя и получателя так, чтобы можно было воспользоваться преимуществами агрегации маршрутов.

Еще одним новым аспектом является таблица политики выбора адресов, которая позволяет администраторам добавить или изменить правила выбора адресов. IPv4 адреса представлены в таблице, как IPv4-mapped IPv6-адреса, и они относятся к области соответствующей адресам IPv6 локально-канальным или глобальным. В RFC-3484 приведен пример таблицы для такой политики:

При выдаче адреса таблица просматривается и ищется запись с наиболее длинным префиксом, соответствующем адресу. После этого присылается соответствующие значения приоритета и метка. Это обеспечивает согласование меток отправителя и получателя и предпочтение родного IPv6 по отношению к IPv4 или различных туннельных адресов (6to4 или v4-совместимых).

Первым шагом при выборе адреса отправителя является формирование списка кандидатов. Вообще, выбор должен согласовываться с интерфейсом и рабочей областью (scope). Следующим шагом является сортировка кандидатов, следуя списку правил, начиная с правила 1:

1. Предпочтителен адрес отправителя, который равен адресу места назначения.
2. Предпочтительна минимальная область действия, которая по крайней мере столь же велика, как и область места назначения. (Это правило является обязательным.)
3. Предпочтителен адрес, который не является нежелательным.
4. Предпочтителен домашний адрес, если только приложение не требует обратного.
5. Предпочтителен адрес исходящего интерфейса для данного места назначения.
6. Предпочтителен адрес, который соответствует метке места назначения в таблице политики.
7. Предпочтителен публичный адрес по сравнению с временным адресом, если только приложение не требует обратного.
8. Использовать адрес с наиболее длинным префиксом, общим с адресом места назначения.

При выборе адреса места назначения следует пользоваться аналогичным набором правил. Основное отличие заключается в том, что выбор места назначения включает в себя запрос, какой отправитель будет использоваться в каждом из вариантов. Кандидаты перечисляются в списке и сравниваются, начиная с правила 1:

1. Избегайте неиспользуемых мест назначения (таких, которые не достижимы или не имеют используемых адресов отправителя ).
2. Предпочтителен адрес места назначения, с областью, согласующейся с адресом отправителя.
3. Предпочтителен адрес места назначения с источником, который не является нежелательным.
4. Предпочтителен адрес места назначения с адресом отправителя, который является домашним адресом, по сравнению с адресом обслуживания (например, care-of address в случае мобильных сервисов).

Care-Of Address (CoA). Маршрутизируемый уникастный адрес, используемый MN (Mobile Node - мобильным узлом) в постороннем канале (любой канал кроме домашнего).

5. Предпочтителен адрес места назначения с источником, который имеет соответствующую метку (в таблице политики).
6. Предпочтителен адрес места назначения с высоким приоритетом (в таблице политики).
7. Предпочтителен адрес места назначения, который достижим при использовании инкапсуляции.
8. Предпочтителен адрес места назначения с минимальной областью действия (scope).
9. Предпочтителен адрес места назначения с источником, имеющим наиболее длинный подходящий префикс.
10. Предпочтителен адрес места назначения, который встречается первым в исходном списке. То есть, порядок сохраняется неизменным.

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

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

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

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

• Ручное присвоение адресов интерфейсам маршрутизаторов.
• Маршрутную информацию и префиксы каналов, анонсируемые маршрутизаторами
• Адреса маршрутизаторов, firewall и пакетных фильтров управления доступом.
• Адреса, присвоенные интерфейсам посредством адресной автоконфигурации.
• Адреса и другую информацию, предоставляемую DHCPv6.
• DNS-записи (AAAA и PTR-рекорды, а также DNSSEC)
• Все другие случаи использования адресов, командных последовательностей, конфигурационных файлов.

Некоторые части сети могут быть перенумерованы независимо.

Процедуры перенумерации рассмотрены в документах RFC-4861 (Neighbor Discovery for IP version 6 (IPv6)), RFC 4862 (IPv6 Stateless Address Autoconfiguration) и RFC-4192 (Procedures for Renumbering an IPv6 Network without a Flag Day).

Многие организации предпочитают получить блоки адресов /48. Это позволяет организации поддерживать до 65,000 субсетей.

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

• RFC-3056 - Connection of IPv6 Domains via IPv4 Clouds,
• RFC-3879 - Deprecating Site Local Addresses,
• RFC-4007 - IPv6 Scoped Address Architecture,
• RFC-4193 - Unique Local IPv6 Unicast Addresses,
• RFC-4291 - IP Version 6 Addressing Architecture.
• RFC-5375 - IPv6 Unicast Address Assignment Considerations

Использование Firewall в условиях IPv6 рассмотрено в RFC 4487 (Mobile IPv6 and Firewalls: Problem Statement). Смотри также RFC-4640 (Problem Statement for bootstrapping Mobile IPv6 (MIPv6)) и RFC-5026 (Mobile IPv6 Bootstrapping in Split Scenario).

DHCPv6 (Dynamic Host Configuration Protocol for IPv6) является протоколом клиент-сервер, который обеспечивает интерфейсам IPv6 автоматическое присвоение адресов и другой конфигурационной информации. DHCPv6 описан в RFC 3315. Это достаточно сложный протокол с большим числом типов сообщений , опций, статусных кодов и таймеров.

Существует несколько расширений DHCPv6, это RFC-3319 (Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers), RFC-3633 (IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6), RFC-3736 (Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6).

Когда клиент DHCP не нуждается в получении IP-адреса от DHCP-сервера, клиент может получить конфигурационную информацию, такую как доступные DNS-серверы или NTP-серверы, обменявшись парой сообщений с DHCP-сервером. Клиент сначала посылает информационный запрос по мультикастному адресу All_DHCP_Relay_Agents_and_Servers. Сервер отреагирует на этот запрос откликом, содержащим конфигурационную информацию. Все адреса, выданные клиенту DHCP-сервером, имеют оговоренные времена действия. Работа DHCP в двухпротокольном режиме определяется документом RFC-4477 (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Dual Stack Issues).

Альтернативным протоколом автоматизации является SLAAC (Stateless Address AutoConfiguration. Он представляет собой нормальным путем получения динамических адресов IPv6, но он не предоставляет такой информации как адреса DNS и NTP серверов и не осуществляет динамических обнавлений DNS. SCAAC не предлагает также централизованного контроля присвоения адресов, который бывает необходим для некоторых сетевых операторов. DHCPv6 отслеживает присвоение адресов. DHCPv6 не описан в рамках IPv6-стандартов, но по мере расширения использования IPv6, нужда в DHCPv6 возрастает.

Предотвращение несанкционированного доступа к сетям IPv6 на первых порах будет затруднено. Это прежде всего связано с типичным размером субсети в IPv6 (2⁶⁴ по сравнению с 256 для типового IPv4). Здесь также трудно запретить использование протокола ICMP, из-за его большей функциональности. Чтобы минимизировать угрозы при внедрении IPv6 рекомендуется предпринять следующее:

• Чтобы ограничить доступ к адресной ситуации, следует использовать различные типы IPv6-адресации (частная адресация, уникальные локальные адреса, разбросанное выделение адресов и т.д.).
• Чтобы усложнить сканирование сети, присваивать идентификаторы субсети и интерфейсов случайным образом.
• Разработать для предприятия политику выборочной фильтрации ICMPv6. Важные для работы сети ICMPv6-сообщения должны быть доступны, остальные следует блокировать.
• Использовать IPsec для аутентификации и конфиденциальности.
• Идентифицировать возможные слабости в защите доступа к сети в среде IPv6.
• Ввести проверки, которые могли быть не нужны при работе с IPv4 из-за низкого уровня угроз (в политике безопасности использовать запреты по умолчанию, а также активировать систему безопасности маршрутизации.
• Уделить повышенное внимание аспектам безопасности для таких механизмов передачи, как протоколы туннелирования.
• Для сетей, использующих исключительно IPv4, блокировать весь трафик IPv6.

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

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

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

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

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

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

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

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

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

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

Примеры:

fedc:ba98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A

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

2. Из-за метода записи некоторых типов 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	адрес обратной связи
::	не специфицированный адрес



3. Альтернативной формой записи, которая более удобна при работе с 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

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

Таблица 4.4.1.1.1. Префиксы

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

Таблица 4.4.1.1.1A

Принципиальным отличием IPv6 от IPv4 является то, что одному интерфейсу может быть выделен не один, а несколько адресов. Teredo представляет собой алгоритм, который позволяет узлам, расположенным за NAT, иметь коннективность путем туннелирования пакетов поверх UDP (см. [1] и RFC-4380 -Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs).

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

В IPv6 определены локальные связи (Link-local). Это относится к локальным сетям или сетевым каналам. Каждый интерфейс IPv6 в LAN должен иметь адрес этого типа. Такие адреса начинаются с FE80::/10. Пакеты с адресом места назначения этого вида не могут маршрутизоваться и не могут переадресоваться за пределы локальной области.

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

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 битовый неструктурированный образ.

Эффективная агрегация адресов IPv6 описана в документе RFC-3531.

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

Рис. 4.4.1.1.2

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

Примером уникастного адресного формата, который является стандартным для локальных сетей и других случаев, где применимы 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 адрес, с тем, чтобы оставить больше места для полей, характеризующих уровни иерархии. Это могут быть идентификаторы интерфейсов, сформированные администрацией локальной сети или организации.

Практика использования адресов IPv6 привела к унификации структура адреса, формат которой представлен на рис. 4.4.1.1.4A. Документ RFC-4291 описывает нотацию префиксов. Префикс сети аналогичен но не тождественен маске субсети в IPv4. IPv4-адреса записываются в нотации CIDR (Classless Inter-domain Routing) . Маска субсети содержит 1 в битах, которые идентифицируют ID-сети. В IPv6 нет маски субсети, но нотация осталась прежней: IPv6-адрес/длина префикса.

Длина префикса определяет, сколько самых левых бит образуют префикс сети. Пример адреса с 32-битным префиксом представлен ниже:

2001:0db8:9095:02e5:0216:cbff:feb2:7474/32

Рис. 4.4.1.1.4A

Случай 48-битного префикса представлен на рис. 4.4.1.1.4Б.

Рис. 4.4.1.1.4Б. 48-битовый сетевой префикс

Правительственные, образовательные, коммерческие и другие сети обычно получают конфигурацию адресов от вышестоящих сервис-провайдеров (ISP) с префиксом сети 48 бит (/48), оставляя для идентификатора субсети и машины 80 бит.

Субсети в пределах организации часто имеют сетевые префиксы 64 бита (/64), оставляя 64 бита для интерфейсов машины. В отличие от IPv4 у интерфейса IPv6 может быть не один, а несколько IP-адресов. ID машины должен использовать 64-битовый идентификатор, который следует за EUI-64 (Extended Unique Identifier), когда используется глобальный префикс (001 до 111), за исключением случая использования мультикастного адреса (1111 1111) . См. рис. 4.4.1.1.4В.

Рис. 4.4.1.1.4В. 64-битовый сетевой префикс

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

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

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

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

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

Рис. 4.4.1.1.5

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

Рис. 4.4.1.1.6

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

Рис. 4.4.1.1.7

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

Рис. 4.4.1.1.8

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

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

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

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

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

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

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

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

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

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

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

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

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

Эникаст-адрес 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

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

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

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

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

Рис. 4.4.1.1.13. Структура мультикастинг-адреса

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

Рис. 4.4.1.1.14. Флаги (R - rendezvous; P - префикс; T - transient)

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

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

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

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

0011 - временный мультикаст-адрес со встроенным уникатсным префиксом и без точки встречи
0111 - временный мультикаст-адрес со встроенным уникатсным префиксом и с точкой встречи

Рис. 4.4.1.1.14A. Формат мультикастинг-адреса для вновь определяемых объектов

Поле p-len задает ширину поля сетевого префикса (до 64 бит). Поле префикса выравнивается по левому краю, остальные биты обнуляются. Ниже представлен пример адреса, взятый из RFC-3306: FF38:0030:3FFE:FFFF:0001:0:1234:5678.

• Мультикаст (FF)
• Переходной со встроенным префиксом (3)
• Область действия - локальный (8)
• Использует префикс длиной 48 бит (30)
• Префикс - 3FFE:FFFF:0001/48
• 32-битовый идентификатор группы 1234:5678

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

Ниже представлены значения поля scope.

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 дейтограммах или встречаться в любых заголовках маршрутизации.

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

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 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.

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

• Её локальный адрес канала для каждого из интерфейсов
• Выделенные уникаст-адреса
• Адрес обратной связи
• Мультикастинг-адрес для обращения ко всем узлам
• Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов
• Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.

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

• Его локальный адрес канала для каждого из интерфейсов
• Выделенные уникаст-адреса
• Адрес обратной связи
• Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.
• Все другие эникастные адреса, которые использовались при маршрутизации.
• Мультикастинг-адрес для обращения ко всем узлам
• Мультикастинг-адрес для обращения ко всем маршрутизаторам
• Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.
• Мультикастные адреса всех прочих групп, принадлежащих маршрутизатору.

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

• Не специфицированный адрес
• Адрес обратной связи
• Мультикаст-префикс (FF)
• Локально используемые префиксы (link-local и site-local)
• Предопределенные мультикаст-адреса
• Префиксы, совместимые с IPv4

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

В 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.

Ниже приведена таблица заголовков расширения со ссылками на RFC-документы, взятая из взятая из документа "IPv6 extension headers and security: Analyzing the risk", Fernando Gont.

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

Опции hop-by-hop

Маршрутизация (routing;тип 0)
Фрагмент
Опции места назначения
Проверка прав доступа (authentication)
Поле безопасных вложений (encapsulating security payload)

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

Таблица 4.4.1.1.1А. Коды поля следующий заголовок

Протокол ICMPv6 выполняет ряд важных функций:

• Автоконфигурации рабочих станций и серверов (RFC-4862)
• Для определения адресных префиксов и другой конфигурационной информации
• Для выявления адресов-дублеров
• Для определения МАС-адресов (L2)
• Для выявления ближайшего маршрутизатора, способного переадресовать пакеты.
• Детектирование изменения адресов канального уровня
• Отслеживание достижимых и недостижимых сетевых объектов

Выявление МАС-адреса по IP осуществляется следующим образом. Пусть МАС-адрес отправителя равен AA-BB-CC-00-00-AA, а его IPv6-адрес - 2001:CB8::1234:5678:AAAA. МАС-адрес будущего адресата - AA-BB-CC-00-00-BB, а IPV6 - 2001:DB8::1234:5678:BBBB. Отправитель посылает мультикаст-сообщение выявления соседа по адресу FF02::1:FF78:BBBB (кто имеет адрес 2001:CB8::1234:5678:BBBB?). В результате посылается сообщение анонсирование соседа по адресу 2001:CB8::1234:5678:AAAA (MAC=AA-BB-CC-00-00-AA) (MAC-адрес отправителя = AA-BB-CC-00-00-BB). Отправитель на основе префикса знает, что уникастный адрес получателя является локальным. При формировании мультикастного адреса места назначения используются 24 младшие бит IPv6-адреса получателя.

IPv6-адрес может находиться в разных состояниях:

• Экспериментальный. Такой адрес является уникальным, но он не может быть присвоен интерфейсу в обычном смысле. Интерфейс игнорирует пакеты, адресованные такому адресу, за исключением ND-пакетов, относящихся к DAD (выявления адресов-дублеров).
• Предпочтительный адрес. Адрес, присваиваемый интерфейсу. Его использование протоколами более высокого уровня не ограничено. Он может использоваться как для посылки, так и при получении пакетов.
• Корректный адрес. Может использоваться в качестве адреса отправителя и получателя, а также при любых операциях марштутизации.
• Некорректный адрес. Адрес, который не присвоен ни одному из интерфейсов. Корректный адрес может стать некорректным, при истечении его времени действия. Такие адреса не могут использоваться в качестве адреса отправителя или получателя.

Рекомендации по фильтрации ICMPv6 в firewall можно найти в RFC 4890, (Recommendation for Filtering ICMPv6 Messages in Firewalls).

Спецификация для внутреннего протокола маршрутизации OSPF содержится в документе RFC-5340. Особенности работы DNS-сервиса для IPv6 рассмотрены в RFC-3596 (DNS Extensions to Support IP Version) и RFC-4472 (Operational Considerations and Issues with IPv6 DNS), RFC-4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) и RFC-3833 (Threat Analysis of the Domain Name System (DNS)). Смотри также RFC-3901 (DNS IPv6 Transport Operational Guidelines). Обратный запрос выявления имени по IP-адресу в случае IPv6=2001:db8:2:3:4:5:678:90ab будет обращен к a.b.0.9.8.7.6.0.5.0.0.0.4.0.0.0.3.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. Подавление нулей и двойные двоеточия здесь при записи адреса использоваться на могут.

Проблема многодомности для IPv6 рассмотрена в документе RFC-4177, RFC-5533 и RFC-5534.

Работа с мобильными устройствами и каналами в рамках IPv6 описана в документе RFC-5555. Использование протоколов IPSec и смежные проблемы для случая IPv6 представлена в RFC-5660 (IPsec Channels), RFC 5406 (Guidelines for Specifying the Use of IPsec Version 2), RFC-5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)), RFC-5723 (Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption), RFC5840 (Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility) и RFC-5739 (IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2).

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

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 заголовком.

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.4.1.1.17

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

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

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

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

Рис. 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.

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

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

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

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

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

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

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

Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 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:

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

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

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

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

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

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

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

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

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

Рис. 4.4.1.1.22.

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

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

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

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

Рис. 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) с указателем на поле смещения фрагмента пакета-фрагмента. Следующие условия не должны реализоваться, но они также рассматриваются как ошибка, если это произойдет:

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

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

Заголовок опции места назначения используется для передачи опционной информации, которая должна анализироваться только узлом (узлами) назначения. Заголовок опции места назначения идентифицируется кодом поля следующий заголовок равным 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 в старших двух битах.

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

Протокол 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, которое следует использовать.

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 секунд), это время можно использовать для задания времени жизни меток потоков.

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

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

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

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

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

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

Любой транспортный или другой протокол верхнего уровня, который включает адреса 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.

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

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

Это приложение дает некоторые советы, как выкладывать поля, при формировании новых опций, предназначенных для использования в заголовке опций 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

Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825]. Смотри также RFC-4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6).

Проблемы безопасности в IPv4 и IPv6 сильно отличаются. Объективными предпосылками таких отличий являются конфиденциальные (private) адреса и криптографически генерируемые адреса. Использование IPSec здесь также носит совершенно иной характер. Свою специфику вносит и техника выявления соседей посредством ICMPv6.

Конфиденциальные адреса могут использоваться приложением клиента, чтобы блокировать отслеживание пользователя, что может быть полезно для защиты внешних коммуникаций. Согласно RFC-4291, интерфейсы, использующие автоконфигурацию, генерируют идентификаторы, базирующиеся на стандарте IEEE EUI-64. Это обеспечивает уникальность, но позволяет отслеживать интерфейс, даже если он переходит из одной сети в другую, или если изменяется префикс сети.

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

RFC-4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) определяет способ генерации и изменения таких временных адресов. Важным требованием при этом является невозможность простого угадывания значений последовательности временных адресов. RFC-4941 рекомендует следовать следующей процедуре.

1. Получить идентификатор интерфейса, который будет использоваться вне этой схемы.
2. Использовать для этого идентификатора криптографическую хэш-функцию и либо запомненное ранее (историческое) значение, либо псевдослучайное 64-битовое число.
3. Использовать результат хэш-функции, чтобы выбрать идентификатор интерфейса и обновить "историческое" значение.
4. Запустить процедуру выявления дублированных адресов (DAD)
5. Установить соответствующие времена жизни и подключиться к мультикаст-группе узла, соответствующей идентификатору интерфейса.
6. Продолжать использовать идентификаторы интерфейса для работающих (но не для новых) соединений.
7. Повторить эту процедуру при подключении к новой сети или при истечении времени таймера.

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

18.1 Криптографически генерируемые адреса

Криптографически генерируемые адреса (CGA), называемые также адреса, базирующиеся на хэшах, предоставляют метод проверки принадлежности адреса отправителя пакета. Идея заключается в выборе пары общего и секретного ключей, пригодных для формирования цифровой подписи, которая может быть верифицирована с помощью общедоступного ключа (см. рис. 4.4.1.1.32A). затем, общедоступный ключ (совместно с другими параметрами) используется для формирование идентификатора интерфейса, общедоступный ключ вкладывается в пакет, и пакет подписывается секретным ключом. После получения, общедоступный ключ может использоваться для проверки адреса и подписи. Атакер без секретного ключа не может подписать фальсифицированный пакет.

Рис. 4.4.1.1.32A. Генерирование криптографических адресов для пар ключей общий-секретный

Для выполнения этой работы нужны четыре процесса:

Отправитель должен:

1. Сформировать пару ключей и соответствующий адрес.
2. Вставить общедоступный ключ в пакет и подписать его секретным ключом.

Получатель должен:

3. Проверить, что адрес отправителя соответствует общедоступному ключу.
4. Верифицировать подпись с помощью общедоступного ключа.

Двухстековая стратегия удобна для перехода от одной технологии к другой, но такая схема обладает уязвимостями обоих протоколов (IPv4 и IPv6), плюс новые уязвимости, связанные с непреднамеренными взаимодействиями между ними. В случае двухстекового варианта машина может поддерживать как IPv4, так и IPv6. Смотри RFC-4554 (Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks). Каждый стек отвественен за конфигурирование своих адресов. Двухстековая схема требует больших сетевых ресурсов.

Документ RFC 4852 (IPv6 Enterprise Network Analysis - IP Layer 3 Focus), содержит хорошие советы относительно работы с двухстековыми системами. RFC 4942 (IPv6 Transition/Coexistence Security Considerations), содержит важные специфические детали совместного использования протоколов:

• Организации должны использовать согласованные политики безопасности как для IPv4, так и для IPv6 (включая firewalls фильтры пакетов).
• Организации должны учитывать новую функциональность IPv6. Эта функциональность может включать мобильность, адресную автоконфигурацию, выявление соседей, конфиденциальные адреса, и криптозащиту IPsec по схеме точка-точка.
• Так как работают оба протокола, может происходить непредусмотренное туннелирование между машинами. В результате может нарушаться политика безопасности.
• Организации должны обновлять IDS и IPS-системы, firewalls, мониторинг, журналирование и аудит, чтобы обеспечить безопасность IPv6 на уровне IPv4. Если туннелированным пакетам разрешено входить в сеть, firewall или системы IDS/IPS должны обеспечивать глубокий просмотр этих пакетов .
• При переходе на IPv6 параметры системы безопасности могут деградировать.

18.2. Иерархическая адресация для целей сегментации безопасности

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

IPv6 отличается от IPv4 не только идентификацией машины, но и регионального провайдера на основе глобальной иерархии, задаваемой RIR (Regional Internet Registry). Сетевой префикс адреса идентифицирует RIR и адрес ISP. IPv6 допускает использование 16 бит субсети (/48) для SLA (Site-Level Aggregation Identifier). Организации могут использовать эти 16 бит для построения иерархии сайта. Предлагаемые методы построения субсетей включают в себя:

• Последовательная нумерация субсетей
• VLAN номер
• Номер AS
• Номер субсети IPv4
• Физическое положение (здание, город, страна и т.д.)
• Функциональный модуль (человеческие ресурсы, операции, финансы и т.д.

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

Оборудование Firewall и IDS, несконфигурированное для распознавания трафика IPv6, может его легко пропускать некоторые виды атак. Хакеры часто используют IPv6, чтобы обойти средства защиты IPv4. Зарегистрированы уже атаки и средств автоконфигурации IPv6. Современные ОС делают доступным IPv6 по-умолчанию, что отрывает дополнительное окно уязвимостей. Чтобы закрыть эти возможности для хакеров следует предпринять следующее:

• Выявлять и блокировать IPv6-оборудование в сетях IPv4.
• Блокировать трафик IPv6 и соответствующе туннели на периметре сети.
• Включить политику использования IPv6 в план безопасности организации.

На первом этапе для обеспечения безопасности можно отказаться от процедур автоконфигурации. Вообще перед началом внедрения IPv6 нужно сформировать последовательность шагов. Одним из пунктов на каждом из этапов должна быть безопасность. Смотри также [2] и [3].

18.3. Туннелирование

На верхнем уровне туннели представляют собой сконфигурированные или автоматические туннели. Сконфигурированные туннели требуют вмешательства системного администратора для задания своих конечных точек. В случае автоматических туннелей узлы определяют конечные точки туннелей сами. Обычно, организация для своей инфраструктуры использует сконфигурированные туннели. Машины используют автоматические туннели для передачи данных назад в IPv4 или для островов IPv6. Сконфигурированные туннели статичны по своей природе, а автоматические туннели являются динамическими. На рис. 4.4.1.1.32B показан общий случай, когда две машины могут работать друг с другом через сеть IPv4.

Рис. 4.4.1.1.32B. Пример сетевого туннелирования IPv6 поверх IPv4

Сетевые администраторы должны понять, что IPv6-туннелирование может происходить помимо их воли и без какого-либо уведомления. Использование оборудования, способного детектировать и фильтровать IPv6-трафик, является крайне важным. IPv4 может туннелировать IPv6-трафик через систему управления безопасности и нарушать тем самым политику управления доступом. В результате, туннели IPv6 поверх IPv4 становятся черным ходом в сеть. На рис. 4.4.1.1.32C проиллюстрировано взаимодействие между IPv6-туннелями и существующей IPv4-сетью.

Рис. 4.4.1.1.32C. Туннели IPv6 поверх IPv4, прозрачные для инфраструктуры IPv4

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

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

• Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6.
• Определен новый домен, предназначенный для обработки запросов по новым адресам.
• Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов.

Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние сосуществования IPv4 и IPv6-адресов обсуждается в [4]. Проблема транспортировки IPv6 через IPv4 (6over4) рассмотрена в RFC-2529 (Transmission of IPv6 over IPv4 Domains without Explicit Tunnels).

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

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

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

Запрос 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.

Проблемы маршрутизации для IPv6 подробно рассмотрены в докладе "Router Security Guidance Activity of the Systems and Network Attack Center (SNAC)" [5], где разобраны могие аспекты безопасности.

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

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

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

Сообщения 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 в предыдущем заголовке. (Заметим: этот код отличается от значения (=1), принятого для ICMP IPv4.)

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

Рис. 4.4.1.1.33. Общий формат заголовка сообщений ICMPv6

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

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

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

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

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

Таблица 4.4.1.1.3. Сообщения об ошибках ICMPv6 и коды типа

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

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

1. Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.
2. Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.
3. Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.
4. В тех случаях, когда протокол интернет-уровня нуждается в передаче сообщения об ошибке ICMPv6 вышерасположенному уровню, тип протокола верхнего уровня извлекается из исходного пакета (содержащегося в теле сообщения об ошибке ICMPv6) и используется для выбора соответствующего протокола верхнего уровня при последующей обработке сообщения об ошибке.

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

5. Сообщение об ошибке 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%!).

Рис. 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 исходного пакета содержит нераспознанный код следующего заголовка.

Рис. 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].

Существенно отличается в IPv6 задача преобразования IP-адреса в МАС-адрес. Здесь для этой цели служит протокол ND (Neighbor Discovery) IPv6 (RFC-4861), который функционально несравненно богаче, чем протокол ARP. Он представляет собой комбинацию нескольких протоколов IPv4: [ARP], [RDISC] (ICMP Router Discovery) и версии переадресации ICMP [ICMPv4]. В IPv4 не существует единого согласованного механизма детектирования недостижимости соседнего узла, хотя в документе "Hosts Requirements" [HR-CL] специфицируются некоторые алгоритмы детектирования недоступности GW.

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

Хотя былой энтузиазм, связанный с переходом IPv4->IPv6, иссяк, проблема осталась (см. "Stop using Internet Protocol Version 4! Four reasons to move entirely to IPv6" Charles C. Sun, ComputerWorld, May 1, 2014). На первое мая 2014 года в США остался только один свободный блок адресов IPv4. В других странах адреса IPv4 закончились уже достаточно давно. Правительство США постановило, что все федеральные агенства должны перейти на IPv6 (до 30-го сентября 2014) и все организации, сотрудничающие с государственными службами, должны как минимум обеспечить совместимость этих технологий. На текущий момент (25 апреля 2014г) 51% всех WEB-сервисов в США уже совместимы с IPv6. Еще 4% структур готовятся перейти на IPv6. Кроме того, 32% из 1281 федеральных доменов .gov обеспечивают совместимость с IPv6, еще 40% готовятся осуществить такой переход. Утверждается, что существующие сетевые инфраструктуры не могут обеспечить эффективную поддержку обоих систем адресации. Еще одним аргументом для перехода на IPv6 является широкое внедрение Интернета вещей.

Литература