Адресация IPv6

Размещено на http://www.allbest.ru/

Адресация IPv6

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



Содержание

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/128	50	0	Обратная связь
::/0	40	1	По умолчанию (включая родной IPv6)
2002::/16	30	2	6to4
::/96	20	3	IPv4 совместимый
::ffff:0:0/96	10	4	IPv4 Mapped

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

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

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

2. Предпочтительна минимальная область действия, которая по крайней мере столь же велика, как и область места назначения. (Это правило является обязательным.)

3. Предпочтителен адрес, который не является нежелательным.

4. Предпочтителен домашний адрес, если только приложение не требует обратного.

5. Предпочтителен адрес исходящего интерфейса для данного места назначения.

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

7. Предпочтителен публичный адрес по сравнению с временным адресом, если только приложение не требует обратного.

8. Использовать адрес с наиболее длинным префиксом, общим с адресом места назначения.

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

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

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

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

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

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

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

6. Предпочтителен адрес места назначения с высоким приоритетом (в таблице политики).

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

8. Предпочтителен адрес места назначения с минимальной областью действия (scope).

9. Предпочтителен адрес места назначения с источником, имеющим наиболее длинный подходящий префикс.

10. Предпочтителен адрес места назначения, который встречается первым в исходном списке. То есть, порядок сохраняется неизменным.

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

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

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

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

· Ручное присвоение адресов интерфейсам маршрутизаторов.

· Маршрутную информацию и префиксы каналов, анонсируемые маршрутизаторами

· Адреса маршрутизаторов, firewall и пакетных фильтров управления доступом.

· Адреса, присвоенные интерфейсам посредством адресной автоконфигурации.

· Адреса и другую информацию, предоставляемую DHCPv6.

· DNS-записи (AAAA и PTR-рекорды, а также DNSSEC)

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

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

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

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

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

· RFC-3056 - Connection of IPv6 Domains via IPv4 Clouds,

· RFC-3879 - Deprecating Site Local Addresses,

· RFC-4007 - IPv6 Scoped Address Architecture,

· RFC-4193 - Unique Local IPv6 Unicast Addresses,

· RFC-4291 - IP Version 6 Addressing Architecture.

· RFC-5375 - IPv6 Unicast Address Assignment Considerations

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

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

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

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

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

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

· Чтобы ограничить доступ к адресной ситуации, следует использовать различные типы IPv6-адресации (частная адресация, уникальные локальные адреса, разбросанное выделение адресов и т.д.).

· Чтобы усложнить сканирование сети, присваивать идентификаторы субсети и интерфейсов случайным образом.

· Разработать для предприятия политику выборочной фильтрации ICMPv6. Важные для работы сети ICMPv6-сообщения должны быть доступны, остальные следует блокировать.

· Использовать IPsec для аутентификации и конфиденциальности.

· Идентифицировать возможные слабости в защите доступа к сети в среде IPv6.

· Ввести проверки, которые могли быть не нужны при работе с IPv4 из-за низкого уровня угроз (в политике безопасности использовать запреты по умолчанию, а также активировать систему безопасности маршрутизации.

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

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

Примеры:

fedc:ba98:7654:3210:FEDC:BA98:7654:3210

1080:0:0:0:8:800:200C:417A

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

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

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

может быть представлено в виде:

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

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

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

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

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

::13.1.68.3

::FFFF:129.144.52.38

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

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

Таблица 4.4.1.1.1

Назначение	Префикс (двоичный)	Часть адресного пространства
Зарезервировано	0000 0000	1/256
Адрес обратной связи для каждого интерфейса [RFC 2460]	0000 0001	1/256
Зарезервировано для NSAP	0000 001	1/128
Зарезервировано для IPX	0000 010	1/128
Не определено	0000 011	1/128
Не определено	0000 1	1/32
Не определено	0001	1/16
Не определено	001	1/8
Провайдерские уникаст-адреса	010	1/8
Не определено	011	1/8
Зарезервировано для географических уникаст-адресов	100	1/8
Не определено	101	1/8
Не определено	110	1/8
Не определено	1110	1/16
Не определено	1111 0	1/32
Не определено	1111 10	1/64
Локальный IPv6-адрес (Пространство уникальных уникастных и эникастных локальных адресов [RFC 4193])	1111 110	1/128 (FC00::/7)
Не определено	1111 1110 0	1/512
Локальные канальные адреса	1111 1110 10	1/1024
Локальные адреса (site)	1111 1110 11	1/1024
Мультикаст-адреса (RFC 4291)	1111 1111	1/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 0	4000::/2 - FC00::/9	Глобальный уникастный и эникастный (невыделенные)
Teredo	0010 0000 0000 0001 0000 0000 0000 0000	2001:0000::/32	Teredo [RFC 4380]
Немаршрути-зируемый	0010 0000 0000 0001 0000 1101 1011 1000	2001:DB8::/32	Немаршрутизируемый. Только для целей документирования [RFC 3849]
6to4	0010 0000 0000 0010	2002::/16	6to4 [RFC 3056]
6Bone	0011 1111 1111 1110	3FFE::/16	Нерекомендуемые. 6Bone тестовое распределение, с 1996 по середину 2006 [RFC 3701]
Уникастный локального канала	1111 1110 10	FE80::/10	Уникастный локального канала
Зарезервировано	1111 1110 11	FEC0::/10	Нерекомендуемые. Формально сайт-локальные адреса, уникастные и эникастные [RFC 3879]
Локальный IPv6-адрес	1111 110	FC00::/7	Пространство уникальных уникастных адресов (и эникастных) [RFC 4193]
Мультикасный	1111 1111	FF00::/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 адресов:

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

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

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

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

Рис. 4.4.1.1.12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Мультикаст (FF)

· Переходной со встроенным префиксом (3)

· Область действия - локальный (8)

· Использует префикс длиной 48 бит (30)

· Префикс - 3FFE:FFFF:0001/48

· 32-битовый идентификатор группы 1234:5678

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FF00:0:0:0:0:0:0:0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До

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

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

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

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

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

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

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

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

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

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

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

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