RFC 4291 IP Version 6 Addressing Architecture

Опубликовано 21.02.2006 автором Nikolai Malykh

Please enter banners and links.

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

Оглавление

Исключено в версии HTML.

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

Петлевой (2.5.3)

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 битов           |
   +-------------------------------+---------------------------------+
   |      префикc подсети          |     идентификатор интерфейса    |
   +-------------------------------+---------------------------------+

Хотя простейший маршрутизатор может не знать внутренней структуры индивидуальных адресов 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 с адресом получателя недопустимо передавать за пределы узла и пересылать на маршрутизаторах 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 2460, December 1998.

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

[AUTH] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC 24023, 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: [email protected]

Stephen E. Deering

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

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

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

[email protected]

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [email protected].

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

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

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

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

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

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

Добавить комментарий

Or