RFC 4291 · февраль 2006
Архитектура адресации IP версии 6
Авторы: R. Hinden, Nokia; S. Deering, Cisco Systems. Категория: процесс стандартизации. Февраль 2006. Заменяет RFC 3513.
Статус документа
Этот документ определяет протокол процесса стандартизации Интернета для интернет-сообщества и приглашает к обсуждению и предложениям по улучшению. Состояние стандартизации и статус протокола приведены в текущем издании «Официальных стандартов протоколов Интернета» (STD 1). Распространение документа не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2006).
Аннотация
Спецификация определяет архитектуру адресации протокола IP версии 6 (IPv6). Документ включает модель адресации IPv6, текстовое представление адресов IPv6, определения индивидуальных (unicast), произвольных (anycast) и групповых (multicast) адресов IPv6, а также адреса, обязательные для узла IPv6.
Этот документ заменяет RFC 3513 «Архитектура адресации IP версии 6».
1. Введение
Спецификация определяет архитектуру адресации протокола IP версии 6. Она включает основные форматы различных типов адресов IPv6: unicast, anycast и multicast.
2. Адресация IPv6
Адреса IPv6 — 128-битовые идентификаторы интерфейсов и наборов интерфейсов; термин «интерфейс» определяется в разделе 2 [IPV6]. Существует три типа адресов:
Unicast: идентификатор одного интерфейса. Пакет, отправленный на unicast-адрес, доставляется интерфейсу, обозначенному этим адресом.
Anycast: идентификатор набора интерфейсов, обычно принадлежащих разным узлам. Пакет, отправленный на anycast-адрес, доставляется одному из обозначенных им интерфейсов — «ближайшему» согласно мере расстояния протоколов маршрутизации.
Multicast: идентификатор набора интерфейсов, обычно принадлежащих разным узлам. Пакет, отправленный на multicast-адрес, доставляется всем обозначенным им интерфейсам.
В IPv6 отсутствуют широковещательные адреса; их функцию выполняют multicast-адреса.
В документе поля адресов получают определённые имена, например subnet. Когда после имени используется термин ID, обозначающий идентификатор, например subnet ID, речь идёт о содержимом соответствующего поля. Когда используется термин prefix, например subnet prefix, речь идёт обо всей части адреса слева до этого поля включительно.
В IPv6 значения, полностью состоящие из нулей или единиц, допустимы для любого поля, если они специально не исключены. В частности, префиксы могут содержать поля с нулевыми значениями или заканчиваться ими.
2.1. Модель адресации
Адреса IPv6 всех типов назначаются интерфейсам, а не узлам. Индивидуальный адрес IPv6 обозначает один интерфейс. Поскольку каждый интерфейс принадлежит одному узлу, любой индивидуальный адрес интерфейса этого узла можно использовать как идентификатор узла.
Все интерфейсы обязаны иметь хотя бы один индивидуальный адрес канальной области действия (link-local); дополнительные обязательные адреса перечислены в разделе 2.8. Один интерфейс также может иметь несколько адресов IPv6 любого типа — unicast, anycast или multicast — и любой области действия. Индивидуальные адреса с областью действия шире канальной не нужны интерфейсам, которые не используются как источник или получатель пакетов IPv6 от несоседних узлов или к ним. Иногда это удобно для интерфейсов точка-точка. У модели адресации есть одно исключение:
Индивидуальный адрес или набор индивидуальных адресов может быть назначен нескольким физическим интерфейсам, если реализация представляет эти физические интерфейсы интернет-уровню как один интерфейс. Это полезно для распределения нагрузки между несколькими физическими интерфейсами.
В настоящее время IPv6 сохраняет модель IPv4, при которой префикс подсети связан с одним каналом. Одному каналу можно назначить несколько префиксов подсетей.
2.2. Текстовое представление адресов
Существуют три общепринятые формы текстового представления адресов IPv6:
1. Предпочтительная форма — x:x:x:x:x:x:x:x, где каждое x состоит из одной–четырёх шестнадцатеричных цифр одного из восьми 16-битовых фрагментов адреса. Примеры:
ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 2001:DB8:0:0:8:800:200C:417A
Ведущие нули отдельного поля записывать не обязательно, но в каждом поле должна быть хотя бы одна цифра, кроме случая, описанного в пункте 2.
2. Из-за некоторых способов распределения отдельных разновидностей адресов IPv6 они часто будут содержать длинные последовательности нулевых битов. Для упрощения записи предусмотрен специальный синтаксис сжатия нулей. Запись :: обозначает одну или несколько групп по 16 нулевых битов. В адресе :: может встречаться только один раз. Этот синтаксис также можно использовать для сжатия нулей в начале или конце адреса.
Например, адреса:
2001:DB8:0:0:8:800:200C:417A — unicast-адрес FF01:0:0:0:0:0:0:101 — multicast-адрес 0:0:0:0:0:0:0:1 — адрес обратной петли 0:0:0:0:0:0:0:0 — неопределённый адрес
можно представить так:
2001:DB8::8:800:200C:417A — unicast-адрес FF01::101 — multicast-адрес ::1 — адрес обратной петли :: — неопределённый адрес
3. Альтернативная форма, иногда более удобная в смешанной среде узлов IPv4 и IPv6, — x:x:x:x:x:x:d.d.d.d. Здесь x — шестнадцатеричные значения шести старших 16-битовых фрагментов адреса, а d — десятичные значения четырёх младших восьмибитовых фрагментов, то есть стандартное представление 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 в бесклассовой междоменной маршрутизации CIDR [CIDR]. Префикс адреса IPv6 записывается так:
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 префикс подсети: 2001:0DB8:0:CD30::/60 объединённая запись: 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60
2.4. Определение типа адреса
Тип адреса IPv6 определяется его старшими битами:
Тип адреса Двоичный префикс Запись IPv6 Раздел Неопределённый 00...0 (128 бит) ::/128 2.5.2 Обратной петли 00...1 (128 бит) ::1/128 2.5.3 Multicast 11111111 FF00::/8 2.7 Link-local unicast 1111111010 FE80::/10 2.5.6 Global unicast всё остальное
Адреса anycast выделяются из пространств адресов unicast любой области действия и синтаксически не отличаются от unicast-адресов.
Общий формат глобальных unicast-адресов описан в разделе 2.5.4. Некоторые специальные подтипы глобальных unicast-адресов со встроенными адресами IPv4 для взаимодействия IPv4 и IPv6 описаны в разделе 2.5.5.
Будущие спецификации могут переопределить один или несколько поддиапазонов пространства Global Unicast для других целей, но до этого реализации должны считать глобальными индивидуальными адресами все адреса, не начинающиеся с перечисленных выше префиксов.
2.5. Индивидуальные адреса
Индивидуальные адреса IPv6 можно агрегировать с префиксами произвольной длины в битах, аналогично адресам IPv4 при бесклассовой междоменной маршрутизации.
В IPv6 существует несколько типов индивидуальных адресов, в частности глобальные (Global Unicast), локальные для площадки (site-local unicast; использование прекращено, см. раздел 2.5.7) и локальные для канала (Link-Local unicast). Существуют также специальные подтипы Global Unicast, например адреса IPv6 со встроенными адресами IPv4. В будущем могут быть определены дополнительные типы и подтипы адресов.
Узлы IPv6 могут обладать значительными или минимальными сведениями о внутренней структуре адреса IPv6 в зависимости от роли узла, например хоста или маршрутизатора. В минимальном случае узел может считать, что индивидуальные адреса, в том числе собственные, не имеют внутренней структуры:
| 128 бит | +----------------------------------------------------------+ | адрес узла | +----------------------------------------------------------+
Несколько более развитый, но всё ещё довольно простой хост может дополнительно знать префиксы подсетей каналов, к которым он подключён; для разных адресов n может иметь разные значения:
| n бит | 128−n бит | +----------------------------+------------------------------+ | префикс подсети | идентификатор интерфейса | +----------------------------+------------------------------+
Хотя очень простой маршрутизатор может не знать внутренней структуры индивидуальных адресов IPv6, маршрутизаторы обычно знают одну или несколько границ иерархии, необходимых для работы протоколов маршрутизации. Известные границы различаются между маршрутизаторами в зависимости от их положения в иерархии маршрутизации.
За исключением знания границы подсети, обсуждавшегося выше, узлам не следует делать предположений о структуре адреса IPv6.
2.5.1. Идентификаторы интерфейсов
Идентификаторы интерфейсов в индивидуальных адресах IPv6 используются для обозначения интерфейсов в канале. Они должны быть уникальными в пределах префикса подсети. Рекомендуется не назначать один идентификатор интерфейса разным узлам в одном канале. Идентификаторы также могут быть уникальны в более широкой области. В некоторых случаях идентификатор интерфейса создаётся непосредственно из адреса этого интерфейса на канальном уровне. Один идентификатор интерфейса может использоваться на нескольких интерфейсах одного узла, если они подключены к разным подсетям.
Уникальность идентификаторов интерфейса не зависит от уникальности адресов IPv6. Например, глобальный индивидуальный адрес может быть создан с идентификатором интерфейса локальной области действия, а link-local-адрес — с идентификатором интерфейса универсальной области действия.
Для всех индивидуальных адресов, кроме начинающихся с двоичного значения 000, требуется, чтобы идентификаторы интерфейса имели длину 64 бита и формировались в модифицированном формате EUI-64.
Идентификаторы интерфейса на основе модифицированного формата EUI-64 могут иметь универсальную область действия, если они получены из универсального идентификатора, например 48-битового MAC IEEE 802 или идентификатора IEEE EUI-64 [EUI64]. Они могут иметь локальную область действия, если глобальный идентификатор недоступен — например, для последовательных каналов или конечных точек туннеля — либо нежелателен, например при использовании временных идентификаторов ради конфиденциальности [PRIV].
Идентификаторы интерфейса в модифицированном формате EUI-64 формируются инверсией бита u — бита universal/local в терминологии IEEE EUI-64 — при формировании из идентификаторов IEEE EUI-64. В полученном модифицированном формате 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| +----+----+----+----+----+----+
Здесь используется стандартный для Интернета порядок битов; u — бит universal/local, g — бит individual/group, c — биты идентификатора компании company_id. В приложении A «Создание идентификаторов интерфейсов в модифицированном формате EUI-64» приведены примеры создания таких идентификаторов.
Инверсия бита u при формировании идентификатора интерфейса нужна, чтобы системным администраторам было легко вручную настраивать неглобальные идентификаторы при отсутствии аппаратных идентификаторов. Ожидается, что это относится, например, к последовательным каналам и конечным точкам туннелей. Альтернативой были бы записи вида 0200:0:0:1, 0200:0:0:2 и т. д. вместо значительно более простых 0:0:0:1, 0:0:0:2 и т. д.
Узлы IPv6 не обязаны проверять уникальность идентификаторов интерфейсов, созданных из модифицированных идентификаторов EUI-64 с битом u, указывающим на универсальную область действия.
Бит universal/local в идентификаторе модифицированного формата EUI-64 предназначен для будущих технологий, способных использовать преимущества идентификаторов интерфейсов универсальной области действия.
Подробности формирования идентификаторов интерфейсов определяются соответствующей спецификацией «IPv6 поверх <канала>», например «IPv6 поверх Ethernet» [ETHER] или «IPv6 поверх FDDI» [FDDI].
2.5.2. Неопределённый адрес
Адрес 0:0:0:0:0:0:0:0 называется неопределённым. Его нельзя назначать какому-либо узлу. Он обозначает отсутствие адреса. Пример использования — поле Source Address пакета IPv6, отправляемого инициализирующимся хостом до того, как он узнал собственный адрес.
Неопределённый адрес нельзя использовать как адрес назначения пакетов IPv6 или в заголовках маршрутизации IPv6. Маршрутизатор IPv6 никогда не должен пересылать пакет IPv6 с неопределённым адресом источника.
2.5.3. Адрес обратной петли
Индивидуальный адрес 0:0:0:0:0:0:0:1 называется адресом обратной петли (loopback). Узел может использовать его для отправки пакета IPv6 самому себе. Его нельзя назначать физическому интерфейсу. Он считается адресом канальной области действия; его можно рассматривать как индивидуальный link-local-адрес виртуального интерфейса, обычно называемого интерфейсом обратной петли, для воображаемого канала, не ведущего никуда.
Адрес обратной петли нельзя использовать как адрес источника пакетов IPv6, отправляемых за пределы одного узла. Пакет IPv6 с адресом назначения обратной петли никогда нельзя отправлять за пределы одного узла или пересылать маршрутизатором IPv6. Пакет с адресом назначения обратной петли, полученный на интерфейсе, должен отбрасываться.
2.5.4. Глобальные индивидуальные адреса
Общий формат глобальных индивидуальных адресов IPv6:
| n бит | m бит | 128−n−m бит | +------------------------+-------------+--------------------------+ | глобальный префикс | идентификатор| идентификатор интерфейса | | маршрутизации | подсети | | +------------------------+-------------+--------------------------+
Глобальный префикс маршрутизации — обычно иерархически структурированное значение, назначенное площадке, то есть группе подсетей или каналов; идентификатор подсети обозначает канал внутри площадки, а идентификатор интерфейса определён в разделе 2.5.1.
Все глобальные индивидуальные адреса, кроме начинающихся с двоичного 000, имеют 64-битовое поле идентификатора интерфейса, то есть n + m = 64, оформленное согласно разделу 2.5.1. Для глобальных индивидуальных адресов, начинающихся с двоичного 000, такого ограничения размера или структуры поля идентификатора интерфейса нет.
Примеры глобальных индивидуальных адресов, начинающихся с двоичного 000, — адреса IPv6 со встроенными адресами IPv4, описанные в разделе 2.5.5. Пример глобальных адресов, начинающихся с двоичного значения, отличного от 000, и потому имеющих 64-битовое поле идентификатора интерфейса, приведён в [GLOBAL].
2.5.5. Адреса IPv6 со встроенными адресами IPv4
Определены два типа адресов IPv6, которые содержат адрес IPv4 в младших 32 битах: совместимый с IPv4 адрес IPv6 (IPv4-Compatible IPv6 address) и отображённый IPv4 адрес IPv6 (IPv4-mapped IPv6 address).
2.5.5.1. Совместимый с IPv4 адрес IPv6
Совместимый с IPv4 адрес IPv6 был определён для содействия переходу на IPv6. Его формат:
| 80 бит | 16 бит | 32 бита | +--------------------------------------+--------+--------------------+ |0000..............................0000| 0000 | адрес IPv4 | +--------------------------------------+--------+--------------------+
Примечание: адрес IPv4, используемый в совместимом с IPv4 адресе IPv6, должен быть глобально уникальным индивидуальным адресом IPv4.
Использование совместимых с IPv4 адресов IPv6 прекращено, поскольку современные механизмы перехода на IPv6 их больше не используют. Новые или обновлённые реализации не обязаны поддерживать этот тип адресов.
2.5.5.2. Отображённый IPv4 адрес IPv6
Определён второй тип адреса IPv6 со встроенным адресом IPv4. Он используется для представления адресов узлов IPv4 в виде адресов IPv6. Формат:
| 80 бит | 16 бит | 32 бита | +--------------------------------------+--------+--------------------+ |0000..............................0000| FFFF | адрес IPv4 | +--------------------------------------+--------+--------------------+
Сведения об использовании отображённого IPv4 адреса IPv6 приведены в [RFC4038].
2.5.6. Индивидуальные адреса IPv6, локальные для канала
Адреса Link-Local предназначены для использования в одном канале. Их формат:
| 10 бит | 54 бита | 64 бита | +----------+---------------------------+----------------------------+ |1111111010| 0 | идентификатор интерфейса | +----------+---------------------------+----------------------------+
Адреса Link-Local предназначены для адресации в одном канале, например при автоматической настройке адресов, обнаружении соседей или отсутствии маршрутизаторов.
Маршрутизаторы не должны пересылать в другие каналы пакеты, имеющие Link-Local-адрес источника или назначения.
2.5.7. Индивидуальные адреса IPv6, локальные для площадки
Адреса Site-Local первоначально предназначались для адресации внутри площадки без необходимости глобального префикса. Их использование прекращено согласно [SLDEP].
Формат адресов Site-Local:
| 10 бит | 54 бита | 64 бита | +----------+---------------------------+----------------------------+ |1111111011| идентификатор подсети | идентификатор интерфейса | +----------+---------------------------+----------------------------+
Специальное поведение этого префикса, определённое в [RFC3513], больше не должно поддерживаться в новых реализациях: они должны рассматривать его как Global Unicast.
Существующие реализации и развёрнутые системы могут продолжать использовать этот префикс.
2.6. Адреса anycast
Адрес anycast IPv6 назначается более чем одному интерфейсу, обычно принадлежащему разным узлам. Пакет, отправленный на такой адрес, маршрутизируется к «ближайшему» интерфейсу с этим адресом согласно мере расстояния протоколов маршрутизации.
Адреса anycast выделяются из пространства индивидуальных адресов с использованием любого определённого формата unicast. Поэтому синтаксически они неотличимы от индивидуальных адресов. Если индивидуальный адрес назначается более чем одному интерфейсу и тем самым превращается в anycast, узлы, которым он назначен, должны быть явно настроены так, чтобы распознавать его как anycast.
Для каждого назначенного адреса anycast существует наиболее длинный префикс P этого адреса, обозначающий топологическую область, в которой находятся все интерфейсы с данным адресом. Внутри области P адрес anycast должен сохраняться в системе маршрутизации отдельной записью, обычно называемой маршрутом к хосту; вне области P адрес anycast может агрегироваться в запись маршрутизации префикса P.
В худшем случае префикс P множества anycast может быть пустым, то есть члены множества могут не иметь топологической локальности. Тогда адрес anycast необходимо хранить как отдельную запись маршрутизации во всём Интернете, что сильно ограничивает масштабируемость числа поддерживаемых таких «глобальных» множеств. Поэтому ожидается, что поддержка глобальных множеств anycast может быть недоступна или значительно ограничена.
Один из предполагаемых способов использования anycast — обозначение набора маршрутизаторов организации, предоставляющей доступ в Интернет. Такие адреса можно использовать как промежуточные в заголовке маршрутизации IPv6, чтобы пакет доставлялся через определённого поставщика услуг или последовательность поставщиков.
Другие возможные применения — обозначение набора маршрутизаторов, подключённых к определённой подсети, или набора маршрутизаторов, обеспечивающих вход в определённый домен маршрутизации.
2.6.1. Обязательный адрес anycast
Адрес anycast Subnet-Router определён заранее. Его формат:
| n бит | 128−n бит | +-------------------------------------------+-----------------+ | префикс подсети | 00000000000000 | +-------------------------------------------+-----------------+
Префикс подсети в адресе anycast обозначает конкретный канал. Синтаксически этот адрес anycast совпадает с индивидуальным адресом интерфейса в канале, идентификатор которого установлен в ноль.
Пакеты, отправленные на адрес anycast Subnet-Router, доставляются одному маршрутизатору подсети. Все маршрутизаторы обязаны поддерживать адреса anycast Subnet-Router для подсетей, в которых у них есть интерфейсы.
Адрес anycast Subnet-Router предназначен для приложений, которым требуется связь с любым одним маршрутизатором из набора.
2.7. Групповые адреса multicast
Адрес multicast IPv6 — идентификатор группы интерфейсов, обычно находящихся на разных узлах. Интерфейс может принадлежать любому числу групп multicast. Формат адресов multicast:
| 8 бит | 4 бита | 4 бита | 112 бит | +----------+--------+--------+-------------------------------------+ | 11111111 | flgs | scop | group ID | +----------+--------+--------+-------------------------------------+
Двоичное значение 11111111 в начале адреса указывает, что это адрес multicast.
flgs — набор четырёх флагов: |0|R|P|T|.
Старший флаг зарезервирован и должен инициализироваться нулём.
T = 0 обозначает постоянно назначенный («общеизвестный») адрес multicast, назначенный Управлением адресного пространства Интернета IANA.
T = 1 обозначает непостоянно назначенный («временный» или «динамически» назначенный) адрес multicast.
Определение и использование флага P приведены в [RFC3306], флага R — в [RFC3956].
scop — четырёхбитовое значение области действия multicast, ограничивающее область группы. Возможные значения:
0 — зарезервировано 1 — область одного интерфейса (Interface-Local) 2 — область одного канала (Link-Local) 3 — зарезервировано 4 — административная область (Admin-Local) 5 — область площадки (Site-Local) 6, 7 — не назначены 8 — область организации (Organization-Local) 9, A, B, C, D — не назначены E — глобальная область (Global) F — зарезервировано
Область Interface-Local охватывает только один интерфейс узла и полезна лишь для передачи multicast через обратную петлю.
Область Link-Local multicast охватывает ту же топологическую область, что и соответствующая область unicast.
Admin-Local — наименьшая область, требующая административной настройки, то есть не выводимая автоматически из физической связности или другой конфигурации, не связанной с multicast.
Site-Local предназначена для охвата одной площадки. Organization-Local предназначена для охвата нескольких площадок, принадлежащих одной организации.
Области с пометкой «не назначена» доступны администраторам для определения дополнительных областей multicast.
Поле group ID идентифицирует постоянную или временную группу multicast в заданной области. Дополнительные определения структуры поля group ID приведены в [RFC3306].
«Значение» постоянно назначенного адреса multicast не зависит от значения области действия. Например, если группе серверов NTP назначен постоянный адрес multicast с 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 в Интернете.
Непостоянно назначенные адреса multicast имеют значение только в заданной области действия. Например, группа, обозначенная непостоянным адресом multicast площадки FF15:0:0:0:0:0:0:101 на одной площадке, никак не связана с группой с тем же адресом на другой площадке, непостоянной группой с тем же group ID в другой области действия или постоянной группой с тем же group ID.
Адреса multicast нельзя использовать как адреса источника в пакетах IPv6 или включать в какие-либо заголовки маршрутизации.
Маршрутизаторы не должны пересылать пакеты multicast за пределы области, указанной полем scop адреса назначения multicast.
Узлы не должны формировать пакеты на адрес multicast с зарезервированным значением поля scop 0; если такой пакет получен, его следует молча отбросить. Узлам не следует формировать пакеты на адрес multicast с зарезервированным значением поля scop F; если такой пакет отправлен или получен, с ним необходимо обращаться так же, как с пакетом на глобальный адрес multicast со scop E.
2.7.1. Предопределённые адреса multicast
Следующие общеизвестные адреса multicast определены заранее. Идентификаторы групп в этом разделе определены для явно указанных значений области действия. Использование этих идентификаторов с любыми другими значениями области при флаге T, равном 0, не допускается.
Зарезервированные адреса multicast: 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 зарезервированы и никогда не должны назначаться какой-либо группе multicast.
Адреса всех узлов (All-Nodes): FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1
Эти адреса multicast обозначают группу всех узлов IPv6 в области 1 — одного интерфейса — или 2 — одного канала.
Адреса всех маршрутизаторов (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
Эти адреса multicast обозначают группу всех маршрутизаторов IPv6 в области 1 — одного интерфейса, 2 — одного канала или 5 — площадки.
Адрес запрашиваемого узла (Solicited-Node): FF02:0:0:0:0:1:FFXX:XXXX
Адреса multicast запрашиваемого узла вычисляются как функция индивидуальных адресов и адресов anycast узла. Такой адрес multicast формируется путём добавления младших 24 битов индивидуального или anycast-адреса к префиксу FF02:0:0:0:0:1:FF00::/104. Результат — адрес multicast в диапазоне от FF02:0:0:0:0:1:FF00:0000 до FF02:0:0:0:0:1:FFFF:FFFF.
Например, адресу IPv6 4037::01:800:200E:8C6C соответствует адрес multicast запрашиваемого узла FF02::1:FF0E:8C6C. Адреса IPv6, различающиеся только старшими битами, например из-за нескольких старших префиксов разных агрегатов, будут сопоставлены с одним адресом запрашиваемого узла. Это уменьшает число адресов multicast, к которым узел должен присоединиться.
Узел обязан вычислять соответствующие адреса multicast запрашиваемого узла и присоединяться к ним на соответствующем интерфейсе для всех индивидуальных и anycast-адресов, настроенных для интерфейсов узла вручную или автоматически.
2.8. Обязательные адреса узла
Хост обязан распознавать следующие адреса как идентифицирующие его самого:
— обязательный Link-Local-адрес каждого интерфейса; — все дополнительные адреса unicast и anycast, настроенные для интерфейсов узла вручную или автоматически; — адрес обратной петли; — адреса multicast всех узлов из раздела 2.7.1; — адрес multicast запрашиваемого узла для каждого своего адреса unicast и anycast; — адреса multicast всех остальных групп, к которым принадлежит узел.
Маршрутизатор обязан распознавать как идентифицирующие его самого все адреса, обязательные для хоста, а также:
— адреса anycast Subnet-Router для всех интерфейсов, для которых он настроен как маршрутизатор; — все остальные настроенные для него адреса anycast; — адреса multicast всех маршрутизаторов из раздела 2.7.1.
3. Вопросы безопасности
Документы об адресации IPv6 не оказывают прямого влияния на безопасность инфраструктуры Интернета. Аутентификация пакетов IPv6 определена в [AUTH].
4. Вопросы IANA
Документ прекращает использование совместимого с IPv4 адреса IPv6. IANA следует продолжать указывать блок адресов, содержащий эти адреса, на http://www.iana.org/assignments/ipv6-address-space как «Reserved by IETF» и не назначать его для других целей. Например:
0000::/8 Reserved by IETF [RFC3513] [1]
IANA добавила для этого блока адресов следующее примечание и ссылку:
[5] Ранее 0000::/96 определялся как префикс совместимого с IPv4 адреса IPv6. Это определение отменено 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
2402, 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. Создание идентификаторов интерфейсов в модифицированном формате EUI-64
В зависимости от характеристик конкретного канала или узла существует несколько подходов к созданию идентификаторов интерфейсов в модифицированном формате 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-битового MAC IEEE с глобальной областью действия:
|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-битовые MAC-адреса IEEE 802 доступны на интерфейсе или узле, реализация может использовать их для создания идентификаторов интерфейсов благодаря их доступности и свойствам уникальности.
Каналы с другими видами идентификаторов
Некоторые виды каналов имеют идентификаторы интерфейсов канального уровня, отличные от IEEE EUI-64 и 48-битовых MAC IEEE 802, например LocalTalk и Arcnet. Для создания идентификатора в модифицированном формате EUI-64 берут идентификатор канала, например восьмибитовый идентификатор узла LocalTalk, и дополняют его нулями слева. Так, восьмибитовый идентификатор узла LocalTalk со значением 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 поверх <канала>». Настоятельно рекомендуется включать алгоритм обнаружения коллизий в любой автоматический алгоритм.
Примечание: [EUI-64] в действительности определяет 0xFF и 0xFF как биты, вставляемые для создания идентификатора IEEE EUI-64 из идентификатора IEEE MAC-48. Значения 0xFF и 0xFE используются при исходном идентификаторе IEEE EUI-48. Неверное значение использовалось в предыдущих редакциях спецификации из-за неправильного понимания различий между идентификаторами IEEE MAC-48 и EUI-48.
Этот документ намеренно сохраняет использование 0xFF и 0xFE, поскольку оно удовлетворяет требованиям к идентификаторам интерфейсов IPv6 — уникальности в канале, — идентификаторы IEEE EUI-48 и MAC-48 синтаксически эквивалентны и на практике это не вызывает проблем.
Приложение B. Изменения относительно RFC 3513
По сравнению с RFC 3513 «Архитектура адресации IP версии 6» внесены следующие изменения:
— ограничения использования адресов IPv6 anycast удалены, поскольку накоплено достаточно опыта их применения, вопросы не специфичны для IPv6 и рабочая группа GROW занимается этой областью; — прекращено использование индивидуального префикса Site-Local. Изменения: Site-Local исключён из специального списка префиксов раздела 2.4; раздел «Индивидуальные адреса IPv6 для локального использования» разделён на разделы об адресах Link-Local и Site-Local; в новый раздел добавлено описание прекращения использования Site-Local; — внесены изменения по замечаниям ответа IAB на обращение Robert Elz: в разделе 2.5 уточнено, что узлам не следует делать предположения о структуре адреса IPv6; текст раздела 2.5.1 и приложения A изменён так, чтобы идентификаторы интерфейса в модифицированном формате EUI-64 с битом u, равным единице, обозначались как универсальные; в разделе 2.5.1 уточнено, что узлы IPv6 не обязаны проверять уникальность идентификаторов интерфейсов в модифицированном формате EUI-64 с битом u, равным единице; — ссылка в разделе 2.5.4 «Глобальные индивидуальные адреса» изменена на RFC 3587; — из примеров удалено упоминание адресов NSAP; — уточнено, что x в текстовом представлении может содержать от одной до четырёх цифр; — прекращено использование совместимого адреса IPv6, поскольку он не применяется механизмами перехода на IPv6; — в раздел 2.7 об адресах multicast добавлены флаги 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
Полное заявление об авторских правах
Copyright (C) The Internet Society (2006).
На документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78; кроме указанных там случаев авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются «КАК ЕСТЬ»; АВТОР ВКЛАДА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН ПРЕДСТАВЛЯЕТ ИЛИ КОТОРАЯ ЕГО ФИНАНСИРУЕТ, ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ, INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ ЧЬИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма каких-либо прав интеллектуальной собственности или иных прав, которые могут относиться к реализации либо использованию технологии, описанной в документе, или относительно доступности лицензий на такие права; IETF также не утверждает, что предпринимала независимые усилия для выявления таких прав. Сведения о процедурах, касающихся прав в документах RFC, приведены в BCP 78 и BCP 79.
Копии раскрытий прав интеллектуальной собственности, представленных секретариату IETF, и любых заверений о предоставлении лицензий либо результатов попыток получить общую лицензию или разрешение на использование таких исключительных прав разработчиками или пользователями спецификации доступны в сетевом реестре IETF по адресу http://www.ietf.org/ipr.
IETF предлагает всем заинтересованным лицам сообщать о любых авторских правах, патентах, патентных заявках или других исключительных правах, которые могут распространяться на технологии, необходимые для реализации стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Благодарность
Финансирование деятельности RFC Editor предоставляется IETF Administrative Support Activity (IASA).
Перевод: RFCNET · rfcnet.ru
Original copyright notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This specification defines the addressing architecture of the IP
Version 6 (IPv6) protocol. The document includes the IPv6 addressing
model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and an
IPv6 node's required addresses.
This document obsoletes RFC 3513, "IP Version 6 Addressing
Architecture".
Hinden Standards Track [Page 1]
RFC 4291 IPv6 Addressing Architecture February 2006
Неофициальный перевод. При расхождениях см. оригинал.