RFC 4291 IP Version 6 Addressing Architecture

Опубликовано 21.02.2006 автором Nikolai Malykh 
Network Working Group                                          R. Hinden
Request for Comments: 4291                                         Nokia
Obsoletes: 3513                                               S. Deering
Category: Standards Track                                  Cisco Systems
                                                           February 2006

 

Архитектура адресации IPv6

IP Version 6 Addressing Architecture

PDF

Статус документа

В этом документе содержится проект стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Аннотация

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

Данный документ отменяет действие RFC 3513, IP Version 6 Addressing Architecture.

1. Введение

Данная спецификация определяет архитектуру адресации протокола IP версии 6. Документ включает основные форматы для разных типов адресов IPv6 (unicast, anycast, multicast).

2. Адресация IPv6

Адреса IPv6 являются 128-битовыми идентификаторами для интерфейсов и групп интерфейсов (термин «интерфейс» трактуется в соответствии с определением в разделе 2 [IPV6]).

Адреса IPv6 делятся на три типа:

Unicast – индивидуальный

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

Anycast

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

Multicast – групповой

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

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

В этом документе для полей адресов используются имена (например, subnet – подсеть). Когда такое имя указывается перед термином ID (например, subnet ID), оно относится к содержимому именованного поля. При использовании имени с термином prefix (например, subnet prefix – префикс подсети), оно относится ко всем адресам, начиная с левого края и включая данное поле.

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

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

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

Для всех интерфейсов требуется наличие хотя бы одного индивидуального адреса Link-Local (в параграфе 2.8 рассказано о дополнительных адресах). Интерфейс может иметь множество адресов IPv6 разных типов (unicast, anycast, multicast) и с разными областями видимости. Наличие индивидуального адреса, видимость которого выходит за пределы канала, не является обязательным для интерфейса, который не используется в качестве источника или получателя пакетов IPv6 при взаимодействии с узлами, не являющимися соседними. Такие адреса иногда удобны для интерфейсов «точка-точка» (point-to-point). Для этой модели адресации имеется одно исключение:

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

В настоящее время IPv6 продолжает использование модели IPv4, в которой с каналом связывается префикс подсети. С одним каналом может быть связано множество префиксов.

2.2. Текстовое представление адресов

Используется три формы представления адресов IPv6 в виде текстовых строк:

  1. Предпочтительной является форма x:x:x:x:x:x:x:x, где x представляет собой от 1 до 4 шестнадцатеричных цифр каждой из восьми 16-битовых частей адреса. Например,

             ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
         2001:DB8:0:0:8:800:200C:417A

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

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

    Например, адреса

             2001:DB8:0:0:8:800:200C:417A   индивидуальный адрес
         FF01:0:0:0:0:0:0:101           групповой адрес
         0:0:0:0:0:0:0:1                адрес петлевого интерфейса
         0:0:0:0:0:0:0:0                не заданный адрес

    могут быть представлены в форме

             2001:DB8::8:800:200C:417A      индивидуальный адрес
         FF01::101                      групповой адрес
         ::1                            адрес петлевого интерфейса
         ::                             не заданный адрес

  3. В среде с использованием адресов IPv4 и IPv6 может быть удобной форма x:x:x:x:x:x:d.d.d.d, где x указывает шестнадцатеричные значения для 6 старших 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

2.3. Текстовое представление адресных префиксов

Текстовое представление адресных префиксов IPv6 похоже на представление префиксов IPv4 в нотации CIDR1 [CIDR]:

      ipv6-address/prefix-length

где

ipv6-address

адрес IPv6 в любом из вариантов записи, представленных в параграфе 2.2;

prefix-length

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

Ниже приведены корректные варианты представления 60-битового префикса 20010DB80000CD3 (шестнадцатеричный):

      2001:0DB8:0000:CD30:0000:0000:0000:0000/60
      2001:0DB8::CD30:0:0:0:0/60
      2001:0DB8:0:CD30::/60

Приведённые ниже варианты представления этого же префикса некорректны.

2001:0DB8:0:CD3/60

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

2001:0DB8::CD30/60

запись слева от / представляет адрес 2001:0DB8:0000:0000:0000:0000:0000:CD30.

2001:0DB8::CD3/60

запись слева от / представляет адрес 2001:0DB8:0000:0000:0000:0000:0000:0CD3

При записи адреса узла с указанием размера префикса (префикс подсети) допускается форма

   2001:0DB8:0:CD30:123:4567:89AB:CDEF/60

где адрес узла 2001:0DB8:0:CD30:123:4567:89AB:CDEF, а префикс подсети 2001:0DB8:0:CD30::/60.

2.4. Идентификация типа адреса

Тип адреса IPv6 задаётся его старшими битами, как показано в таблице.

Тип адреса

Двоичный префикс

Нотация IPv6

Параграф

Не заданный

00…0 (128 битов)

::/128

2.5.2

Петлевой

00…1 (128 битов)

::1/128

2.5.3

Групповой

11111111

FF00::/8

2.7

Индивидуальный на канале

1111111010

FF80::/8

2.5.6

Глобально индивидуальный

все остальные

Адреса Anycast берутся из пространств индивидуальных адресов (любой области действия) и синтаксически не отличимы от индивидуальных адресов.

Общий формат глобальных индивидуальных адресов (Global Unicast) описан в параграфе 2.5.4. Некоторые подтипы таких адресов специального назначения, которые содержат в себе адреса IPv4 (для взаимодействия IPv4-IPv6), описаны в параграфе 2.5.5.

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

2.5 Индивидуальный адрес

Индивидуальный адрес IPv6 может объединяться с префиксами произвольного размера, подобно тому, как это делается для IPv4 CIDR.

Существует несколько типов индивидуальных адресов IPv6, в частности, глобальные (Global Unicast), локальные для сайта (site-local) (устаревший тип, см. параграф 2.5.7) и локальные для канала (Link-Local). Имеются также подтипы Global Unicast специального назначения (такие, как IPv6 со встроенным адресом IPv4). В будущем могут быть определены дополнительные типы или подтипы адресов.

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

   |                           128 битов                             |
   +-----------------------------------------------------------------+
   |                           адрес узла                            |
   +-----------------------------------------------------------------+

Более умный (но все же, простой) хост может в дополнение к этому знать префикс подсети для подключённого канала (разные адреса могут использовать разные значения n), как показано ниже

   |          n битов              |           128-n битов           |
   +-------------------------------+---------------------------------+
   |      префикс подсети          |     идентификатор интерфейса    |
   +-------------------------------+---------------------------------+

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

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

2.5.1 Идентификаторы интерфейсов

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

Отметим, что уникальность идентификаторов интерфейсов не связана с уникальностью адресов IPv6. Например, адрес Global Unicast может быть создан с областью действия «локальный интерфейс», а адрес Link-Local – с глобальной.

Для всех индивидуальных адресов, которые не начинаются с двоичной последовательности 000, идентификаторы интерфейсов должны иметь размер 64 бита и использовать модифицированный формат EUI-64 (Modified EUI-64).

Идентификаторы интерфейсов в модифицированном формате EUI-64 могут иметь глобальную область действия, если они созданы на основе универсальных маркеров (например, IEEE 802 MAC, IEEE EUI-64 [EUI64]), или иметь локальную область действия в тех случаях, когда глобальные маркеры недоступны (например, последовательный канал, конечные точки туннеля) или их использование нежелательно (например, временные маркеры для обеспечения приватности [PRIV]).

Идентификаторы интерфейсов в формате Modified EUI-64 создаются путём инвертирования бита u (universal/local – глобальный/локальный в терминах IEEE EUI-64) при формировании идентификатора интерфейса из идентификатора IEEE EUI-64. В результирующем идентификаторе Modified EUI-64 бит u имеет значение 1 для индикации глобальной области действия и 0 для локальной. Первые три октета идентификатора IEEE EUI-64 в двоичном формате имеют вид

          0       0 0       1 1       2
         |0       7 8       5 6       3|
         +----+----+----+----+----+----+
         |cccc|ccug|cccc|cccc|cccc|cccc|
         +----+----+----+----+----+----+

при использовании принятого в Internet порядка битов. U указывает флаг universal/local, g – флаг individual/group (индивидуальный/групповой), а c – биты company_id. Примеры создания идентификаторов в формате Modified EUI-64 содержит Приложение A. Создание идентификаторов Modified EUI-64.

Смысл инвертирования бита u при формировании идентификатора интерфейса заключается в упрощении системным администраторам настройки неглобальных идентификаторов при недоступности аппаратных маркеров. Это будет актуально, например, для последовательных каналов и конечных точек туннелей. Другим вариантом было бы использование формы 0200:0:0:1, 0200:0:0:2 и т. п. взамен более простой формы 0:0:0:1, 0:0:0:2 и т. п.

Узлы IPv6 не обязаны проверять уникальность идентификаторов интерфейсов, созданных с использованием модифицированных маркеров EUI-64 и имеющих установленный бит u.

Наличие бита u в идентификаторах формата Modified EUI-64 позволяет в будущем создавать технологии, которые могут получить преимущества в результате применения идентификаторов с глобальной областью действия.

Детали формирования интерфейсов определены в соответствующих спецификациях вида IPv6 over <link> (например, IPv6 over Ethernet [ETHER] или IPv6 over FDDI [FDDI].

2.5.2. Незаданный адрес

Адрес 0:0:0:0:0:0:0:0 называется незаданным (unspecified). Такой адрес недопустимо присваивать какому-либо узлу и значение указывает лишь отсутствие адреса. Примером использования такого адреса может служить поле Source Address пакетов IPv6, переданных при инициализации хоста, который ещё не знает своего адреса.

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

2.5.3. Адрес петлевого интерфейса

Индивидуальный адрес 0:0:0:0:0:0:0:1 называется адресом loopback (петлевой интерфейс). Он может использоваться узлом IPv6 для передачи пакетов самому себе. Такой адрес недопустимо присваивать какому-либо физическому интерфейсу. Область действия такого адреса считается локальной (Link-Local) и его можно рассматривать, как индивидуальный адрес Link-Local виртуального интерфейса (обычно его называют «петлевым» – loopback), который не ведёт никуда.

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

2.5.4. Глобальные адреса

Общий формат уникальных в глобальном масштабе индивидуальных адресов (Global Unicast) IPv6 показан ниже.

   |         n битов        |   m битов |       128-n-m битов        |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

Global routing prefix содержит глобальный индекс маршрутизации (обычно из глобальной иерархической структуры), присвоенный сайту (кластер подсетей/каналов), subnet ID – идентификатор канала на данном сайте, interface ID – идентификатор интерфейса, определённый в параграфе 2.5.1.

Все глобальные индивидуальные адреса, не начинающиеся с двоичной последовательности 000, имеют 64-битовое поле идентификатора интерфейса ID (т.е. n + m = 64), формат которого описан в параграфе 2.5.1. Адреса Global Unicast, начинающиеся с двоичной последовательности 000, не имеют такого ограничения на размер и структуру поля interface ID.

Примерами глобальных индивидуальных адресов, начинающихся с 000, являются адреса IPv6 со встроенными адресами IPv4, описанные в параграфе 2.5.5. Примеры глобальных адресов, не начинающихся с 000 (и, следовательно, имеющих 64-битовое поле interface ID) можно найти в [GLOBAL].

2.5.5. Адреса IPv6 со встроенными адресами IPv4

Определены два типа адресов IPv6 для передачи адреса IPv4 в младших 32 битах. Это совместимые с IPv4 адреса IPv6 (IPv4-Compatible IPv6) и отображённые на IPv4 адреса IPv6 (IPv4-mapped IPv6).

2.5.5.1. Совместимые с IPv4 адреса IPv6

Адреса IPv4-Compatible IPv6 были определены для упрощения перехода на IPv6. Совместимые адреса используют формат:

   |                80 битов              | 16 |      32 бита        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|0000|    адрес IPv4       |
   +--------------------------------------+----+---------------------+

Примечание. Адрес IPv4 в совместимом адресе IPv6 должен быть уникальным в глобальном масштабе индивидуальным адресом IPv4.

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

2.5.5.2. Отображённые на IPv4 адреса IPv6

Второй тип адресов IPv6 с вложенным адресом IPv4 обеспечивает представление адресов IPv4 в виде адресов IPv6, как показано ниже.

   |                80 битов              | 16 |      32 бита        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    адрес IPv4       |
   +--------------------------------------+----+---------------------+

Использование отображённых адресов описано в [RFC4038].

2.5.6. Локальные для канала индивидуальные адреса IPv6

Адреса Link-Local используются только на одном канале и имеют формат:

   |   10     |
   |  битов   |         54 бита         |          64 бита           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

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

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

2.5.7. Локальные для сайта индивидуальные адреса IPv6

Адреса Site-Local были изначально предложены для внутрисайтовой адресации без использования глобального префикса. В соответствии с [SLDEP] использование таких адресов отменено.

Формат адресов Site-Local показан ниже.

   |   10     |
   |  битов   |         54 бита         |          64 бита           |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

Специальное поведение данного префикса, определённое в [RFC3513] недопустимо поддерживать в новых реализациях (т. е. новые реализации должны трактовать такие адреса, как Global Unicast).

В существующих реализациях использование данного префикса может продолжаться.

2.6. Anycast-адреса

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

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

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

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

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

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

2.6.1. Обязательный Anycast-адрес

Anycast-адрес маршрутизатора подсети (Subnet-Router) является предопределенным и имеет формат:

   |                        n битов                 |   128-n битов  |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | 00000000000000 |
   +------------------------------------------------+----------------+

Поле subnet prefix в адресе anycast представляет собой префикс, указывающий конкретный канал. Такой anycast-адрес синтаксически эквивалентен индивидуальному адресу интерфейса на канале с нулевым значением идентификатора интерфейса.

Пакеты, отправленные по адресу Subnet-Router anycast2, будут доставляться одному из маршрутизаторов подсети. Все маршрутизаторы должны поддерживать адреса Subnet-Router anycast для подсетей, с которыми они соединены.

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

2.7. Групповые адреса

Групповые адреса IPv6 являются идентификаторами для групп интерфейсов (обычно на разных узлах). Интерфейс может входить в любое число multicast-групп. Формат групповых адресов показан ниже.

   |   8    |  4 |  4 |                  112 битов                  |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

Двоичная последовательность 11111111 в начале адреса показывает, что адрес является групповым.

                                    +-+-+-+-+
      flgs - набор из 4 флагов:     |0|R|P|T|
                                    +-+-+-+-+

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

T = 0 показывает выделенный на постоянной основе (well-known – общеизвестный) групповой адрес. Такие адреса распределяются IANA.

T = 1 указывает временный (transient – переходящий или dynamic – динамический) групповой адрес.

Определение и использование флага P описано в документе [RFC3306].

Определение и использование флага R описано в документе [RFC3956].

Поле scop представляет собой 4-битовый идентификатор области действия адреса, служащий для топологического ограничения multicast-групп.

0 резерв;

1 локальная для интерфейса;

2 локальная для канала;

3 резерв;

4 административно локальная (Admin-Local);

5 локальная для сайта;

6 (не задана);

7 (не задана);

8 локальная для организации;

9 (не задана);

A (не задана);

B (не задана);

C (не задана);

D (не задана);

E глобальная;

F резерв.

Локальная для интерфейса (Interface-Local) область включат только один интерфейс узла и полезна лишь для loopback-передачи групповых пакетов.

Локальная для канала (Link-Local) область совпадает топологически с соответствующей областью индивидуальной адресации.

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

Локальная для сайта (Site-Local) область включает один сайт.

Локальная для организации (Organization-Local) включает множество сайтов одной организации.

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

Поле group ID идентифицирует multicast-группу (постоянную или временную) в масштабе области действия адреса. Дополнительная информация о структуре поля group ID представлена в документе [RFC3306].

Трактовка выделенных на постоянной основе (permanently-assigned) групповых адресов не зависит от области действия адресов. Например, адрес NTP servers group выделен на постоянной основе с group ID = 101 (шестнадцатеричное) и

FF01:0:0:0:0:0:0:101 указывает все серверы NTP на одном интерфейсе с отправителем (т. е. на том же узле);

FF02:0:0:0:0:0:0:101 указывает все серверы NTP на одном канале с отправителем;

FF05:0:0:0:0:0:0:101 указывает все серверы NTP на одном сайте с отправителем;

FF0E:0:0:0:0:0:0:101 указывает все серверы NTP в сети Internet.

Временные multicast-адреса имеют значение только в данной области действия. Например, группа с временным, локальным для сайта multicast-адресом FF15:0:0:0:0:0:0:101 на одном сайте никак не связана с группой, имеющей такой же адрес на другом сайте, а также с другими временными группами с тем же group ID в другой области действия или с постоянными группами с тем же group ID.

Групповые адреса недопустимо использовать в качестве адресов отправителя пакетов IPv6 и в заголовках Routing.

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

Узлам недопустимо генерировать пакеты, направляемые по групповым адресам с нулевым значением поля scop. При получении таких пакетов они должны отбрасываться без уведомления. Узлам не следует генерировать пакеты, направляемые по групповым адресам с полем scop, содержащим зарезервированное значение F. При получении таких пакетов они должны трактоваться, как пакеты с глобальным групповым адресом (scop = E).

2.7.1. Предопределённые групповые адреса

Ниже перечислены предопределённые общеизвестные адреса multicast. Значения group ID в данном параграфе определены для явных областей действия. Использование этих значений group ID для любой другой области действия с флагом T = 0 не допускается.

Зарезервированные групповые адреса:

                                      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

Адреса из приведённого списка являются резервными и их не следует присваивать каким-либо multicast-группам.

Адреса для всех узлов (All Nodes):

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

Перечисленные выше адреса указывают группу из всех узлов IPv6 зоны действия 1 (interface-local) или 2 (link-local).

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

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

Перечисленные выше адреса указывают группу из всех узлов IPv6 зоны действия 1 (interface-local), 2 (link-local) или 5 (site-local).

Адрес запрошенных узлов (Solicited-Node):

                               FF02:0:0:0:0:1:FFXX:XXXX

Адрес Solicited-Node рассчитывается, как функция индивидуальных и anycast-адресов путём добавления 24 младших битов адреса unicast или anycast в конец префикса FF02:0:0:0:0:1:FF00::/104, что даёт групповой адрес из диапазона от FF02:0:0:0:0:1:FF00:0000 до FF02:0:0:0:0:1:FFFF:FFFF.

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

Узел должен рассчитать и присоединить (к соответствующему интерфейсу) групповой адрес Solicited-Node для всех адресов unicast и anycast, которые настроены (вручную или автоматически) на всех интерфейсах узла.

2.8. Обязательные адреса узлов

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

  • Требуемый адрес Link-Local на каждом интерфейсе.

  • Все дополнительные адреса Unicast и Anycast, заданные для интерфейсов узла вручную или автоматически.

  • Адрес loopback.

  • Все групповые адреса All-Nodes, определённые в параграфе 2.7.1.

  • Групповые адреса Solicited-Node для каждого из своих индивидуальных и anycast-адресов.

  • Групповые адреса для всех групп, в которые узел входит.

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

  • Адреса Subnet-Router Anycast для всех интерфейсов, на которых активизирована маршрутизация.

  • Все остальные адреса Anycast, которые настроены на маршрутизаторе.

  • Групповые адреса All-Routers, определённые в параграфе 2.7.1.

3. Вопросы безопасности

Документы по адресации IPv6 не оказывают прямого влияния на безопасность инфраструктуры Internet. Аутентификация пакетов IPv6 определена в [AUTH].

4. Взаимодействие с IANA

Действие документа IPv4-Compatible IPv6 address отменяется настоящим документом. IANA следует продолжать указывать список адресных блоков этого типа на странице http://www.iana.org/assignments/ipv6-address-space как Reserved by IETF и не выделять их для каких-либо иных целей. Например,

0000::/8 Reserved by IETF [RFC3513] [1]

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

[5] 0000::/96 был ранее определён, как IPv4-Compatible IPv6 address. Это определение отменено RFC 4291.

Агентство IANA обновило соответствующим образом ссылки на архитектуру адресации IPv6 в своих реестрах.

5. Благодарности

Авторы благодарят Paul Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, Tatuya Jinmei, Suresh Krishnan и Mahmood Ali за их вклад в подготовку документа.

6. Литература

6.1. Нормативные документы

[IPV6] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 24603, December 1998.

6.2. Дополнительная литература

[AUTH] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC 24024, November 1998.

[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy”, RFC 1519, September 1993.

[ETHER] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, December 1998.

[EUI64] IEEE, “Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority”, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.

[FDDI] Crawford, M., “Transmission of IPv6 Packets over FDDI Networks”, RFC 2467, December 1998.

[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, “IPv6 Global Unicast Address Format”, RFC 3587, August 2003.

[PRIV] Narten, T. and R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 3041, January 2001.

[RFC3513] Hinden, R. and S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture”, RFC 3513, April 2005.

[RFC3306] Haberman, B. and D. Thaler, “Unicast-Prefix-based IPv6 Multicast Addresses”, RFC 3306, August 2002.

[RFC3956] Savola, P. and B. Haberman, “Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address”, RFC 3956, November 2004.

[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition”, RFC 4038, March 2005.

[SLDEP] Huitema, C. and B. Carpenter, “Deprecating Site Local Addresses”, RFC 3879, September 2004.

Приложение A. Создание идентификаторов Modified EUI-64

В зависимости от характеристик конкретного канала или узла имеется множество вариантов создания идентификаторов интерфейса в формате Modified EUI-64.

Каналы и узлы с идентификаторами IEEE EUI-64

Единственным изменением, которое требуется для преобразования идентификаторов IEEE EUI-64 в идентификаторы интерфейсов, является инверсия бита u (universal/local). Ниже приведён пример уникального в глобальном масштабе идентификатора IEEE EUI-64.

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

Символом c обозначены биты выделенного компании идентификатора company_id, 0 – значение бита universal/local, показывающее глобальную область действия, g – бит individual/group, а m указывает биты выбранного производителем идентификатора расширения. Идентификатор интерфейса IPv6 для этого случая имеет вид:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

Единственным изменением является смена значения бита universal/local.

Каналы и узлы с 48-битовыми MAC-адресами IEEE 802

[EUI64] определяет способ создания идентификаторов IEEE EUI-64 из 48-битовых MAC-адресов IEEE. Это осуществляется путём вставки двух октетов с шестнадцатеричными значениями 0xFF и 0xFE (см. примечание в конце этого приложения) в середину 48-битового MAC-адреса (между company_id и заданным производителем идентификатором). Ниже приведён пример уникального в глобальном масштабе 48-битового адреса IEEE MAC.

   |0              1|1              3|3              4|
   |0              5|6              1|2              7|
   +----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+

Символом c обозначены биты выделенного компании идентификатора company_id, 0 – значение бита universal/local, показывающее глобальную область действия, g – бит individual/group, а m указывает биты выбранного производителем идентификатора расширения. Идентификатор интерфейса для этого случая имеет вид:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

При доступности 48-битового адреса IEEE 802 MAC (для интерфейса или узла) реализация может использовать его для создания идентификатора интерфейса.

Каналы с идентификаторами других типов

Существует множество типов каналов с интерфейсами канального уровня, идентификаторы которых отличаются от IEEE EUI-64 и IEEE 802 MAC. Примерами могут служить LocalTalk и Arcnet. Метод создания идентификаторов Modified EUI-64 на основе таких идентификаторов канального уровня (например, 8-битовых идентификаторов LocalTalk) заключается в дополнении слева нужного количества нулей. Например, для узла LocalTalk с 8-битовым идентификатором 0x4F интерфейс будет иметь идентификатор:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

Отметим, что в результате бит universal/local получает значение 0, указывающее локальную значимость идентификатора.

Каналы без идентификаторов

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

При отсутствии встроенного идентификатора канала предпочтительно использовать универсальный идентификатор другого интерфейса или один из идентификаторов узла. В этом случае ни один из интерфейсов данного узла, подключённых к той же подсети, не может использовать такой же идентификатор.

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

  • задание вручную;

  • использование порядкового номера узла;

  • использование специфического для узла маркера.

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

Выбор подходящего алгоритма зависит от канала и реализации. Детали формирования идентификаторов интерфейсов определены в соответствующих спецификациях IPv6 over <link>. Настоятельно рекомендуется реализовать в алгоритме выбора идентификаторов механизм обнаружения конфликтов.

Примечание. [EUI-64] определяет 0xFF и 0xFF в качестве битов, вставляемых в 48-битовые адреса IEEE MAC-48 для создания идентификаторов EUI-64. Значения 0xFF и 0xFE были выбраны в начале работы с идентификаторами IEEE EUI-48. Некорректное значение использовалось в ранних версиях спецификации в результате непонимания различий между идентификаторами IEEE MAC-48 и EUI-48.

В этом документе осознанно сохраняется использование значений 0xFF и 0xFE, поскольку они соответствуют требованиям к идентификаторам интерфейсов IPv6 (уникальность на уровне канала), а идентификаторы IEEE EUI-48 и MAC-48 синтаксически эквивалентны и на практике проблем не возникает.

Приложение B. Отличия от RFC 3513

Ниже перечислены изменения по сравнению с документом RFC 3513, IP Version 6 Addressing Architecture.

  • Удалены ограничения на использование адресов IPv6 anycast, поскольку на основании большого опыта их применения стало ясно, что проблема не является спецификой IPv6. Работу в этом направлении продолжает группа GROW.

  • Отменено использование префикса индивидуальных адресов Site-Local. Изменения включают:

    • удаление Site-Local из списка специальных префиксов в параграфе 2.4;

    • деление параграфа Local-use IPv6 Unicast Addresses на два параграфа Link-Local IPv6 Unicast Addresses и Site-Local IPv6 Unicast Addresses;

    • Добавление текста с описанием отказа от адресов Site-Local.

  • Внесены изменения, связанные с ответом IAB на запрос Robert Elzappeal. Изменения включают:

    • в параграф 2.5 добавлено разъяснение того, что не следует принимать допущений о структуре адресов IPv6;

    • изменён текст параграфа 2.5.1 и Приложения A с указанием формата идентификаторов интерфейсов Modified EUI-64 с установленным битом u (1) в качестве универсального;

    • в параграф 2.5.1 добавлено разъяснение того, что узлы IPv6 не обязаны проверять уникальность идентификаторов формата Modified EUI-64 с установленным битом u.

  • Изменены ссылки, указанные в параграфе 2.5.4 как Global Unicast Addresses, на RFC 3587.

  • Удалено упоминание адресов NSAP в примерах.

  • Разъяснено, что x в текстовом представлении может содержать от 1 до 4 цифр.

  • Отменены адреса IPv6 Compatible Address, поскольку они не были использованы в механизмах перехода на IPv6.

  • В параграфе 2.7 добавлены флаги R и P для групповых адресов и указаны определяющие их документы.

  • Редакционные правки.

Адреса авторов

Robert M. Hinden

Nokia

313 Fairchild Drive

Mountain View, CA 94043

USA

Phone: +1 650 625-2004

EMail: bob.hinden@nokia.com

Stephen E. Deering

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Classless Inter-Domain Routing – бесклассовая междоменная маршрутизация.

2Любой маршрутизатор подсети.

3Документ признан устаревшим и заменен RFC 8200. Прим. перев.

4Документ признан устаревшим и заменен RFC 4302. Прим. перев.

 

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.