up next index search
   UP: 4.4.1 IP-протокол
    Next: 4.4.1.2 IP-туннели

4.4.1.1 Адресация IPv6

Семенов Ю.А. (ИТЭФ-МФТИ)
Semenov Yu (ITEP-MIPT)

1.Терминология
2.Формат заголовка IPv6
2.1Выбор адресов
3.IP версия 6 архитектуры адресации
4.Модель адресации
4.1.Представление записи адресов (текстовое представление адресов)
4.2.Представление типа адреса
4.3.Уникастные адреса
4.3.1.Примеры уникастных адресов
4.4.Неспецифицированный адрес
4.5.Адрес обратной связи
4.6.IPv6 адреса с вложенными IPv4 адресами
4.7.NSAP адреса
4.8.IPX Адреса
4.9.Провайдерские глобальные уникаст-адреса
4.10.Локальные уникаст-адреса IPv6
4.11.Эникаст-адреса
4.12.Мульткаст-адреса
4.12.1.Предопределенные мультикаст-адреса
4.13.Необходимые адреса узлов
5.Заголовки расширения IPv6
5.1.Порядок заголовков расширения
6.Опции
6.1.Опции заголовка hop-by-hop (шаг за шагом)
7.Маршрутный заголовок
8.Заголовок фрагмента
9.Заголовок опций места назначения
10.Отсутствие следующего заголовка
11.О размере пакетов
12.Метки потоков
13.Приоритет
14.О протоколе верхнего уровня
14.1Контрольные суммы верхнего уровня
15.Максимальное время жизни пакета
16.Максимальный размер поля данных для протоколов высокого уровня
17.Приложение A. Рекомендации по формированию опций
18.Соображения безопасности
18.1Криптографически генерируемые адреса
18.2Иерархическая адресация для целей сегментации безопасности
18.3Туннелирование
19.Расширение DNS для поддержки IP версии 6
19.1. Определение новой ресурсной записи и домена
19.2.Модификации существующих типов запроса
20.Протокол управляющих сообщений (ICMPv6) для спецификации IPv6
20.1.ICMPv6 (ICMP для IPv6)
20.2.Общий формат сообщений
20.3.Сообщения об ошибках ICMPv6
20.4.Информационные сообщения ICMPv6

В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: “TCP and UDP with Bigger Addresses (TUBA)”; “Common Architecture for the Internet (CatnIP)” и “Simple Internet Protocol Plus (SIPP) [смотри “Протоколы и ресурсы Интернет” Семенов Ю.А., Радио и связь, М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.

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

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

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

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

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

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

C 30-го сентября 2012 года планируется перевести все агентства федерального правительства США, к 30-му сентября 2014 года этот процесс должен быть завершен. Смотри The 7 Deadly Traps of IPv6 Deployment - and How to Avoid Them. Попытки остаться с IPv4, используя NAT, достаточно бессмысленны, так как современные технологии требуют реализации слишком большого числа сессий, работающих в параллель (до 500). Торможение внедрения IPv6 препятствует использованию беспроводной техники 4G/LTE, которая ориентирована исключительно на IPv6. Следует также учесть, что альтернативы переходу на IPv6 нет, можно только обсуждать время, когда это следует делать. Препятствует такому переходу ряд обстоятельств. Во-первых, некоторое снижение пропускной способности из-за увеличения размера заголовка. Во-вторых, необходимость адаптации программ управления и мониторинга. В-третьих, необходимость переписывания некоторых прикладных программ, например, фильтрующих SPAM. Существуют также проблемы, сопряженные с обеспечением безопасности (стандартные методы с ACL не работают).

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

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

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

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

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

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

Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885 и RFC-4861 (обновленная версия). Протокол ICMPv6 выполняет также функцию получения данных о соседях (аналог протокола ARP). Для этой цели используется посылка мультикастинг-сообщений.

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

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

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

Справедливо также предположение, что и в больших локальных сетях единовременного перехода от IPv4 к IPv6 не произойдет. А это потребует переделки архитектуры локальной сети (см. рис. ниже, а также Dual Stack Network). Аналогичные проблемы встают и перед региональными сервис-провайдерами (рис. 3 приведенной выше ссылки).

Двух-стековая схема локальной сети (возможный вариант)

Полезную информацию по этой теме можно найти в документе RFC 5969, IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) – Protocol Specification.

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

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

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

В документе 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)).

Мобильный IPv6 (MIPv6) является улучшенным протоколом, поддерживающим роуминг для мобильных объектов, так что он может перемещаться из одной сети в другую без потери коннективности IP-уровня (как это определено в RFC-3775). Документ RFC-3344, поддержка IP-мобильности для IPv4, описывает концепции мобильного IP и спецификации для IPv4. Несмотря на это, использование мобильного IP с IPv4 имеет множество ограничений, таких как ограниченное адресное пространство, зависимость от протокола ARP, и вызовы, связанные с переключениями при переходе из точки доступа к другой. Мобильный IPv6 использует большое адресное поле IPv6 и систему выявления соседей (RFC-4861), которая упрощает проблему такого переключения на сетевом уровне, сохраняя соединение с приложением и сервисами, когда устройство временно меняет свой IP-адрес. Мобильный IPv6 вводит также новые концепции безопасности, такие как оптимизация маршрутов (RFC-4449), когда потоки данных между исходным агентом и мобильным узлом должны быть достаточно безопасными. Основные компоненты системы мобильных коммуникаций при IPv6 показаны на рис. 4.4.1.1.1A. (смотри [1] Guidelines for the Secure Deployment of IPv6.) Сначала устанавливается соединение через туннель с домашним резидентным агентом (НА). Все коммуникации должны быть криптографически защищены.

Рис. 4.4.1.1.1A. Основные компоненты MIPv6

Ниже на рис. 4.4.1.1.1Б представлена логика обменов между MN (Mobile Node - мобильный узел) и HA (Home Agent). HoA - Home Address; TSi - traffic selector—initiator).

Рис. 4.4.1.1.1Б. Диалог между MN и HA

Обмен IKEv2 подробно рассмотрен в RFC 4877.

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 приведен пример таблицы для такой политики:

ПрефиксПриоритетМеткаИспользование
::1/128500Обратная связь
::/0401По умолчанию (включая родной IPv6)
2002::/163026to4
::/96203IPv4 совместимый
::ffff:0:0/96104IPv4 Mapped

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

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

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

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

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

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

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

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

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

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

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

Процедуры перенумерации рассмотрены в документах 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 субсетей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

::13.1.68.3
::FFFF:129.144.52.38

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

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

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

НазначениеПрефикс (двоичный)Часть адресного пространства
Зарезервировано0000 00001/256
Адрес обратной связи для каждого интерфейса [RFC 2460]0000 00011/256
Зарезервировано для NSAP0000 0011/128
Зарезервировано для IPX0000 0101/128
Не определено0000 0111/128
Не определено0000 11/32
Не определено00011/16
Не определено0011/8
Провайдерские уникаст-адреса0101/8
Не определено0111/8
Зарезервировано для географических уникаст-адресов1001/8
Не определено1011/8
Не определено1101/8
Не определено11101/16
Не определено1111 01/32
Не определено1111 101/64
Локальный IPv6-адрес (Пространство уникальных уникастных и эникастных локальных адресов [RFC 4193])1111 1101/128 (FC00::/7)
Не определено1111 1110 01/512
Локальные канальные адреса1111 1110 101/1024
Локальные адреса (site)1111 1110 111/1024
Мультикаст-адреса (RFC 4291)1111 11111/256

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

Таблица 4.4.1.1.1A

Тип адресаПрефикс (двоичный)Нотация IPv6Использование
Вложенный IPv4-адрес00…1111 1111 1111 1111 (96 бит)::FFFF/96Префикс для IPv4-адресов, вложенных в IPv6-адреса
Обратная связь00…1 (128 бит)::1/128Адрес обратной связи для каждого интерфейса [RFC 2460]
Глобальный уникастный01 – 1111 1100 04000::/2 – FC00::/9Глобальный уникастный и эникастный (невыделенные)
Teredo0010 0000 0000 0001 0000 0000 0000 00002001:0000::/32Teredo [RFC 4380]
Немаршрути-зируемый0010 0000 0000 0001 0000 1101 1011 10002001:DB8::/32Немаршрутизируемый. Только для целей документирования [RFC 3849]
6to40010 0000 0000 00102002::/166to4 [RFC 3056]
6Bone0011 1111 1111 11103FFE::/16Нерекомендуемые. 6Bone тестовое распределение, с 1996 по середину 2006 [RFC 3701]
Уникастный локального канала1111 1110 10FE80::/10Уникастный локального канала
Зарезервировано1111 1110 11FEC0::/10Нерекомендуемые. Формально сайт-локальные адреса, уникастные и эникастные [RFC 3879]
Локальный IPv6-адрес1111 110FC00::/7Пространство уникальных уникастных адресов (и эникастных) [RFC 4193]
Мультикасный1111 1111FF00::/8Мультикастное адресное пространство [RFC 4291]

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

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

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

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

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

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

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

Рис. 4.4.1.1.2

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

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

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

Рис. 4.4.1.1.3

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

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

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

Рис. 4.4.1.1.4

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

Практика использования адресов 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-битовый сетевой префикс

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

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

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

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

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

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

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

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

4.7. NSAP адреса

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

Рис. 4.4.1.1.7

4.8. IPX Адреса

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

Рис. 4.4.1.1.8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.4.1.1.12

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

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

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

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

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

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

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

Рис. 4.4.1.1.14. Флаги (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.

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

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

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

FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0

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

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

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

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

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

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

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

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

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

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

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

FF02:0:0:0:0:1:0000:0000
до
FF02:0:0:0:0:1:FFFF:FFFF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующий заголовок Протокол Ссылка

0

IPv6 Hop-by-Hop Options RFC 2460

4

IPv4 encapsulation RFC 2003

41

IPv6 encapsulation RFC 2473

43

Routing Header for IPv6 RFC 2460

44

Fragment Header for IPv6 RFC 2460

50

Encap Security Payload (ESP) RFC 4303

51

Authentication Header (AH) RFC 4302

59

No Next Header for IPv6 RFC 2460

60

Destination Options for IPv6 RFC 2460

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

Опции hop-by-hop

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

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

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

Следующий заголовок (NH)Код заголовкаОписание
Опции Hop-by-hop0Используется опциями, которые работают с промежуточными маршрутизаторами
Маршрутизация43Маршрутизация отправителя
Фрагментация44Обрабатывается конечным получателем
Опции места назначения60Используется для опций конечного получателя
Заголовок аутентификации (AH)51Используется IPSec
Инкапсулированное поле данных безопасности (ESP)50Защита целостности и конфиденциальности (IPSec)
Мобильность135Используется для управления мобильностью
ПротоколКод заголовкаОписание
TCP6Для транспортного протокола ТСР
UDP17Для транспортного протокола UDP
IPv6-in-IPv641IP-IP-туннели
GRE47Туннели Generic Routing Encapsulation
ICMPv658Протокол ICMPv6
Отсутствие следующего заголовка59Часто используется ESP
OSPF89Протокол OSPFv3
PIM103Протокольно независимая маршрутизация для мультикастинга
SCTP132Stream Control Transmission Protocol

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

Выявление МАС-адреса по 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-адрес может находиться в разных состояниях:

Рекомендации по фильтрации 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).

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

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

IPv6 заголовок
Заголовок опций hop-by-hop
Заголовок опций места назначения (destination options header, (1) )
Заголовок маршрутизации
Заголовок фрагмента
Заголовок authentication (2)
Заголовок безопасных вложений (encapsulating security payload, (2) )
Заголовок опций места назначения (destination options header (3) )
Заголовок верхнего уровня.

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

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

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

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

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

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

6. Опции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.4.1.1.17

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

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

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

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

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

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


Опция Jumbo Payload (необходимо выравнивание: 4n + 2)

Рис. 4.4.1.1.19.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

else

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

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

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

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

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

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

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

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

else { уменьшить hop limit на 1
повторно направить пакет модулю IPv6 для отправки новому адресату }
}
}
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.4.1.1.22.

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

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

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

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


Рис. 4.4.1.1.23.

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

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

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

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

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

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

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

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

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

Рис. 4.4.1.1.24.

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

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

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

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

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

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

где

pl.orig - поле длины данных восстановленного пакета.
pl.first - поле длины данных первого пакета-фрагмента.
fl.first - длина фрагмента, следующего за заголовком первого пакета-фрагмента.
fo.last - Поле смещения фрагмента в заголовке последнего пакета-фрагмента.
fl.last - длина фрагмента, следующего за заголовком фрагмента последнего пакета-фрагмента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13. Приоритет

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

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

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

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

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

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

14. О протоколе верхнего уровня
14.1 Контрольные суммы верхнего уровня

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

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

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

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

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

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

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

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

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

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

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

Пример 1

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

Рис. 4.4.1.1.27.

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

Рис. 4.4.1.1.28

Пример 2

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

Рис. 4.4.1.1.29

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

Рис. 4.4.1.1.30

Пример 3

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

Рис. 4.4.1.1.31

Рис. 4.4.1.1.32

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

Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825]. Смотри также 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. Проверить, что адрес отправителя соответствует общедоступному ключу.
  5. Верифицировать подпись с помощью общедоступного ключа.

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

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

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

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

Оборудование Firewall и IDS, несконфигурированное для распознавания трафика 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-адреса, определены следующие расширения:

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

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

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

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

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

20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6 (RFC-1885)

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

20.1. ICMPv6 (ICMP для IPv6)

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

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

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

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

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

1 destination unreachable (место назначения недоступно)
2 packet too big (пакет слишком велик)
3 time exceeded (время превышено)
4 parameter problem (проблема с параметрами)

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

128 echo request (Запрос эхо)
129 echo reply (Эхо-отклик)
130 group membership query (запрос участия в группе)
131 group membership report (отчет об участии в группе)
132 group membership reduction (сокращение числа участников в группе)

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

Номер сообщенияТип сообщенияПоле кода
1Адресат недостижим0 = нет маршрута до адресата
1 = Взаимодействие с адресатом административно запрещено
2 = Вне зоны достижимости для отправителя
3 = Адрес недостижим
4 = Порт недостижим
5 = Source address failed ingress/egress policy
6 = Маршрут до места назначения отвергнут
2Пакет слишком длиненУстанавливается равным 0 (нулю) отправителем и игнорируется получателем
3Время истекло0 = Превышен лимит шагов
1 = Превышено время сборки фрагментов
4Проблема с параметрами0 = Обнаружено ошибочное поле заголовка
1 = Обнаружен нераспознанный код следующего заголовка
100 и 101Частные экспериментыRFC 4443
127Зарезервировано для расширения функций сообщений об ошибках ICMPv6RFC 4443

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

Номер сообщенияТип сообщенияПоле кода
128Эхо запросRFC-4443. Используется для команд ping
129Эхо отклик
130Запрос мультикаст-слушателяRFC-2710. Используется для управления мультикаст -группами
131Отчет мультикаст-слушателя
132Мультикаст-слушатель оформлен
133Запрос маршрутизатораRFC-4861. Используется для обнаружения соседа и автоконфигурации
134Анонсирование маршрутизатора
135Запрос соседа (RFC-4861)
136Анонсирование соседа
137Переадресация сообщения
200 и 201Частные экспериментыRFC-4443
255Зарезервировано для расширения возможностей информационных сообщений ICMPv6RFC-4443

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поля IPv6:

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

Поля ICMPv6:

Тип = 1
Код = 0 - нет маршрута до места назначения
1 - связь с адресатом административно запрещена
2 - не сосед
3 - адрес не достижим
4 - порт не достижим

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

Описание

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

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

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

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

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

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

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

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

Поля IPv6:

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

Поля ICMPv6:

Тип 2
Код 0
mtu mtu следующего шага.

Описание

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

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

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

Поля ICMPv6:

Тип 3
Код 0 - при передаче превышен лимит числа шагов
1 - превышено время восстановления сообщения из фрагментов.

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

Описание

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

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

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

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

Поля ICMPv6:

Тип 4
Код 0 - встретилась ошибка в поле заголовка
1 - встретился неопознанный код поля следующий заголовок
2 - встретилась неопознанная опция IPv6
Указатель. Идентифицирует смещение в октетах в пакете, вызвавшем ошибку.

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

Описание

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

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

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

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

Поля IPv6:

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

Поля ICMPv6:

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

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

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

Описание

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

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

Поля IPv6:

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

Поля ICMPv6:

Тип 129
Код 0
Идентификатор. Идентификатор из исходного запроса эхо (echo request).
Номер по порядку. Номер по порядку из исходного запроса эхо.
Информация. Данные из исходного запроса эхо.

Описание

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

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

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

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

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

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

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

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

Поля IPv6:
Адрес места назначения

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

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

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

Тип 130 - Запрос членства в группе
131 - Отчет о членстве в группе
132 - Сокращение членства в группе
Код 0
Максимальное время отклика

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

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

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

Описание

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

Существенно отличается в 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 является широкое внедрение Интернета вещей.

Литература

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

  1. Guidelines for the Secure Deployment of IPv6. Recommendations of the National Institute of Standards and Technology. Sheila Frankel, Richard Graveman, John Pearce, Mark Rooks (NIST US; 188 страниц.) Достаточно полное описание самого протокола и совершенно незаменимое руководство по внедрению и конфигурированию сети с поддержкой IPv6.
  2. A Profile for IPv6 in the U.S. Government – Version 1.0. Special Publication 500-267 NIST. Recommendations of the National Institute of Standards and Technology. Doug Montgomery, Stephen Nightingale, Sheila Frankel and Mark Carson
  3. Malware Tunneling in IPv6. US-CERT. Статья посвящена возможностям использования легальных средств IPv6-туннелирования для вредоносных целей, а также средствам и методам противодействия угрозам.
  4. THC-IPV6. Май 2005 г
  5. Router Security Configuration Guide Supplement - Security for IPv6 Routers. Router Security Guidance Activity of the Systems and Network Attack Center (SNAC). Neal Ziring, 23 May 2006 Version: 1.0

   UP: 4.4.1 IP-протокол
    Next: 4.4.1.2 IP-туннели