RFC 4007 IPv6 Scoped Address Architecture

Network Working Group                                         S. Deering
Request for Comments: 4007                                 Cisco Systems
Category: Standards Track                                    B. Haberman
                                                      Johns Hopkins Univ
                                                               T. Jinmei
                                                                 Toshiba
                                                             E. Nordmark
                                                        Sun Microsystems
                                                                 B. Zill
                                                               Microsoft
                                                              March 2005

IPv6 Scoped Address Architecture

Архитектура адресов IPv6 с ограниченной областью действия

PDF

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

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

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

Аннотация

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

1. Введение

Протокол IP версии 6 включает поддержку адресов с разными областями действия (scope), т. е. глобальных и неглобальных (например, link-local). Хотя неглобальная адресация применяется в IPv4 для приватных адресов (net 10 и т. п.) и групповых адресов с администрируемой областью действия, в IPv6 понятие области действия адреса формально включено в базовую архитектуру. Этот документ определяет архитектурные характеристики, ожидаемое поведение и применение адресов IPv6 с разными областями действия.

Хотя текущая спецификация архитектуры адресов [1] определяет индивидуальные адреса для сайта (site-local), рабочая группа IPv6 решила отказаться от этого синтаксиса и использования [5] и в настоящее время изучает другие формы локальной адресации IPv6. Применение новых форм локальных адресов будет документировано, а в этом документе намеренно рассматриваются лишь адреса link-local и multicast (групповые).

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [2].

3. Основные термины

Термины link (канал), interface (интерфейс), node (узел), host (хост) и router (маршрутизатор) определены в [3]. Определения областей действия индивидуальных (unicast) адресов (link-local и global) и групповых (multicast) адресов (interface-local, link-local и т. п.) даны в [1].

4. Область действия адреса

Каждый адрес IPv6, отличный от незаданного (unspecified) имеет конкретную область действия, т. е. топологическое пространство, в котором адрес может применяться как уникальный и дентификатор для интерфейса или набора интерфейсов. Область действия кодируется как часть адреса, как указано в [1].

Для индивидуальных адресов в этом документе рассматриваются две определённые области действия:

локальная для канала (Link-local), где адрес является уникалльным идентификатором интерфейса лишь на канале, с которым интерфейс соединён;
глобальная, где адрес является уникальным в масштабе всей сети Internet.

Индивидуальный адрес IPv6 для петлевого интерфейса (loopback), ::1, относится к области link-local воображаемого канала, к которому подключён loopback-интерфейс.

Незаданный адрес, ::, является особым случаем. Он не имеет какой-либо области действия и в соответствии [1] его недопустимо назначать какому-либо узлу. Однако следует отметить, что реализация может применять свют семантику для незаданных адресови разрешать их применение в конкретной области действия. Например, реализация может использовать такой адрес для представления адреса any в своих интерфейсах API. В таких случаях реализация может считать незаданный адрес с конкретной областью действия для представления «любого адреса из этой области». Данный документ не запрещает такое использование, если оно ограничено рамками реализации.

В [1] определены адреса IPv6 со вложенным адресом IPv4 как часть глобальных адресов. Таким образом, эти адреса имеют глобальную область действия в архитектуре адресации IPv6. Однако реализаци могут для удобства применять такие адреса с иной областью действия. Например, в [6] назначаются автоматически задаваемые адреса link-local IPv4 (из префикса 169.254.0.0/16 [7]) и преобразуются в адреса IPv6, сопоставленные с IPv4, для выбора адреса получателя среди адресов IPv4 и IPv6. Это неявно означает, что адреса IPv6, сопоставленные с IPv4, эквивалентные автоматически заданным адресам IPv4 link-local, имеют локальную область действия. Данный документ не исключает такое использование, если оно происходит в рамках реализации.

Адреса anycast [1] выделяются из пространства индивидуальных (unicast) адресов и имеют такие же свойства для области действия. Все заявления этого документа для адресов unicast применимы и к anycast-адресам.

Для групповых адресов имеется 14 возможных областей действия, от локальной для интерфейса (interface-local) до глобальной (включая link-local). Область interface-local охватывает лишь один интерфейс и групповые адреса с такой областью действия полезны лишь для петлевой (loopback) доставки групповых пакетов в рамках одного узла, например, для обмена данными между процессами в одном компьютере. В отличии от индивидуального адреса loopback, локальный для интерфейса групповой адрес может быть назначен любому интерфейсу.

Между областями действия имется соотношения размеров:

для unicast область link-local меньше глобальной области;
для multicast области с меньшими значениями в субполе scop группового адреса (параграф 2.7 в [1]) меньше областей с большими значениями, причём область interface-local является наименьшей, а global — наибольшей.

Однако две области разных размеров могут охватывать одну и ту же часть топологии. Например, (групповой) сайт может иметь один канал и охватываться областями link-local и site-local.

5. Зоны областей действия

Зона области действия, или просто зона, — это подключенная часть топологии данной области действия. Например, набор каналов, соединённых маршрутизаторами в рамках конкретного multicast-сайта и интерфейсы, подключённые к этим каналам, образуют одну зону области multicast site-local.

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

Зона, к которой относится конкретный неглобальный адрес, не кодируется в самом адресе, а определяется контекстом, например, интерфейсом, служащим для приёма или передачи. Таким образом, адрес из данной (не глобальной) области действия, может использоваться в других зонах этой области. Например, два разных физических канала могут иметь узлы с адресом link-local fe80::1.

Зоны разных областей действия создаются, как описано ниже.

Каждый интерфейс узла включает одну зону области interface-local (только для multicast).
Каждый канал и подключённые к нему интерфейсы включают одну зону области link-local (unicast и multicast).
Имеется одна зона глобальной области (unicast и multicast), включающая все каналы и интерфейсы Internet.
Границы зон в областях, отличных от interface-local, link-local, global, должны определяться и настраиваться администраторами сетей.

Границы зон относительно стабильны и не меняются при краткосрочных изменениях топологии. Таким образом, требование подключённости топологии внутри зоны подразумевает включение каналов и интерфейсов, которые могут присоединяться время от времени. Например, домашний узел или сеть с доступом в Internet по коммутируемой телефонной линии, подключающиеся к сайту (multicast) работодателя, могут считаться частью зоны работодателя (multicast) site-local даже при разрыве телефонного соединения. Аналогично, отказ маршрутизатора, интерфейса или канала, вызывающий разделение зоны, фактически не делит её на несколько зон и получившиеся в результате части считаются относящимися к одной и той же зоне.

Ниже указаны дополнительные свойства зон.

Границы зон проходят по узлам, а не по каналам (отметим, что глобальная зона не имеет границы, а границца зоны interface-local включает лишь один интерфейс).
Зоны одной области действия не могут перекрываться, т. е. иметь общие интерфейсы или каналы.
Зона данной области действия (меньше глобальной) полностью попадает в зоны большей области действия, т. е. меньшая зона не может включать большую часть топологии, нежели более крупная зона, с которой она имеет общие каналы или интерфейсы.
Каждай зона должна быть «выпуклой» (convex) с точки зрения маршрутизации, т. е. пакеты, переданные с интерфейса другому интерфейсы той же зоны, недопустимо маршрутизировать за пределы зоны. Однако следует отметить, что при наличии в зоне туннельного канала (например, IPv6-over-IPv6 [8]), сеть нижележащего уровня туннеля может выходить за пределы зоны без нарушения «выпуклости».

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

6. Индексы зон

Поскольку один и тот же неглобальный адрес может применяться в нескольких зонах одной области действия (например, адрес fe80::1 на двух разных физических каналах), а узел может иметь интерфейсы в разные зоны одной области действия (например, маршрутизатор может быть подключён к разным каналам), узел должен иметь внутренние средства идентификации зоны, к которой относится неглобальный адрес. Это достигается путём присвоения в рамках узла разных индексов каждой зоне одной области действия, к которой подключён данный узел, и внутреннего использования адресов в соответствии и индексом зоны. Назначение индексов показано на рисунке 1.

 ---------------------------------------------------------------
| Узел                                                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|  /--link1--\ /--------link2--------\ /--link3--\ /--link4--\  |
|                                                               |
|  /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\  |
 ---------------------------------------------------------------
        :           |           |           |           |
        :           |           |           |           |
        :           |           |           |           |
 (Воображаемый    =================       Канал      Туннель
 канал loopback)      Ethernet        point-to-point

Рисунок . Пример индексов зоны.

редставленный на рисунке узел имеет 5 интерфейсов:

интерфейс loopback к воображаемому каналу (никуда не ведёт);

два интерфейса в один канал Ethernet;

интерфейс в канал point-to-point;

туннельный интерфейс (например, абстрактная конечная точка туннеля IPv6-over-IPv6 [8], предположительно организованного через Ethernet или соединение point-to-point link).

Таким образом, узел подключён к 5 зонам interface-local, указанным индексами интерфейсов от 1 до 5. Поскольку два интерфейса Ethernet подключены к одному каналу, узел подключён лишь к 4 зонам link-local, указанным индексами каналов от 1 до 4. Отметим, что даже рот организации туннеля через Ethernet туннельный канал имеет свой индекс, отличающийся от индекса зоны канала Ethernet.

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

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

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

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

Уникальный индекс для каждого интерфейса.
Уникальный индекс канала для каждого интерфейса.

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

Таким образом, принятое по умолчанию назначение индексов зон, показанных на рисунке 1, приведено на рисунке 2. Ручная настройка потребуется, например, для назначения одного индекса канала двум интерфейсам Ethernet.

 ---------------------------------------------------------------
| Узел                                                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|  /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\  |
|                                                               |
|  /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\  |
 ---------------------------------------------------------------
        :           |           |           |           |
        :           |           |           |           |
        :           |           |           |           |
 (Воображаемый    =================       Канал      Туннель
 канал loopback)      Ethernet        point-to-point

Рисунок . Пример индексов зоны по умолчанию.

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

Индивидуальный адрес loopback, ::1, не может быть назначен какому либо иному интерфейсу (не loopback). Поэтому рекомендуется при назначении ::1 без индекса зоны или с принятым по умолчанию индексом считать этот адрес относящимся к зоне loopback link-local, независимо от выбора принятой по умолчанию зоны для link-local. В этом случае для узлов с единственным непетлевым интерфейсом (например, один интерфейс Ethernet), что является общим случаем, адресам link-local не требуется задавать индекс зоны. Адрес ::1 без индекса всегда будет относиться к зоне link-local, содержащей интерфейс loopback. Все прочие адреса link-local без индекса будут относиться к зоне link-local, содержащей непетлевой интерфейс (при условии задания по умолчанию зоны, содержащей такой интерфейс).

По причине требования к зоне данной области действия полностью находиться в зоне большей области (см. раздел 5) два интерфейса, назначенные разным зонам области S должны также обноситься к разнам зонам всех областей меньше S. Таким образом, назначение вручную разных индексов для одной области может потребовать автоматического назначения разных индексов зон в меьших областях. Предположим, например, что вручную заданы индексы site-local 1 и 2 (рисунок 1) и сайт 1 содержит каналы 1 — 3, а сайт 2 — только канал 4. Такая конфигурация приведёт к автоматическому созданию соответствующих индексов admin-local 1 и 2, поскольку область admin-local меньше области site-local.

С учётом сказанного, полный набор индексов для примера на рисунке 1 показан на рисунке 3.

 ---------------------------------------------------------------
| Узел                                                          |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|  /--------------------site1--------------------\ /--site2--\  |
|                                                               |
|  /-------------------admin1--------------------\ /-admin2--\  |
|                                                               |
|  /--link1--\ /--------link2--------\ /--link3--\ /--link4--\  |
|                                                               |
|  /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\  |
 ---------------------------------------------------------------
        :           |           |           |           |
        :           |           |           |           |
        :           |           |           |           |
 (Воображаемый    =================       Канал      Туннель
 канал loopback)      Ethernet        point-to-point

Рисунок . Пример полных индексов зоны.

Хотя в приведённых примерах показано, что значения индексов зон назначаются последовательно для каждой области действия, начиная с 1, на деле значения индекса зоны могут быть произвольными. Реализация может выбирать значения по своему усмотрению при условии уникальности значения индекса каждой зоны во всех областях является уникальным в рамках узла. Знасение о следует резервировать для принятой по умолчанию зоны. Реализации, следующие рекомендациям базового API [10], должны применять значения индексов, которые могут быть представлены полем sin6_scope_id структуры sockaddr_in6.

7. Передача пакетов

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

Хотя для указания зоны достаточно задать выходной интерфейс (поскольку каждый интерфейс подключён не более чем к одной зоне каждой области действия), во многих случаях такая конкретизация избыточна. Например, при передаче по индивидуальному адресу link-local с узла, имеющего несколько интерфейсов в соответствующий канал (необычная конфигурация), протокол вышележащего уровня может не принимать во внимание используемый для передачи интерфейс и предпочтёт отдать это на откуп уровню IP. Таким образом, протоколу вышележащего уровня требуется возможность задать индекс зоны при передаче по неглобальному адресу (не адрес loopback).

8. Приём пакетов

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

9. Пересылка

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

Зона адреса получателя определяется областью действия адреса и принявшим пакет интерфейсом. Интерфейс для следующего узла (next-hop) выбирается по адресу получателя в (концептуальной) таблице маршрутизации, связанной с зоной (см. раздел 10), которая содержит лишь связанные с зоной интерфейсы.
После выбора интерфейса next-hop рассматривается адрес отправителя. Как и для адреса получателя индекс зоны определяется областью действия адреса и принявшим пакет интерфейсом. Если отправка пакета в интерфейс next-hop приведёт к выходу пакета из зоны адреса источника (т. е. произойдёт переход границы зоны адреса отправителя), пакет отбрасывается. Кроме того, при индивидуальном () адресе получателя отправителю исходного пакета передаётся сообщение ICMP Destination Unreachable [4] с кодом 2 (выход за пределы области действия адреса отправителя). Отметим, что код 2 ещё не назначен в [4], но IANA пересмотрит выделение этого значения и документ [4] будет пересмотрен с учётом этого.

Следует отметить, что описанная выше процедура применима к адресам link-local, несмотря на отмену индивидуальных адресов site-local. Таким образом, при получении маршрутизатором с адресом получателя link-local, не являющимся одним из адресов link-local этого маршрутизатора на приёмном канале, ожидается, что маршрутизатор попытается переслать пакет адресату через этот канал (при условии успешного определения адреса получателя на канальном уровне по протоколу Neighbor Discovery [9]). Пересылаемый пакет может быть передан обратно через приёмный интерфейс или другой интерфес того же канала.

При получении узлом адресованного ему пакета с заголовком Routing, содержащим ненулевое значение Segments Left (параграф 4.4 в [3]) сначала проверяется область действия следующего идреса из заголовка Routing. Если эта область меньше области действия исходного адреса получателя, узел должен отбросить пакет. В иных случаях узел заменяет адрес получателя следующим адресом из заголовка Routing, затем применяются указанные ниже правила пересылки.

Зона нового адреса получателя определяется областью действия следующего адреса и принявшим пакет интерфейсом. Интерфейс следующего узла определяется, как описано выше (первое правило).
После выбора интерфейса next-hop рассматривается зона адреса источника по второму правилу (см. выше).

Проверка области действия следующего адреса гарантирует, что при поступлении пакета к его конечному получателю с адресом link-local принимающий узел сможет узнать, что пакет порождён на канале. Это поможет принимающему узлу отправить пакет отклика с адресом конечного получателя в поле отправителя без нарушения зоны источника.

Отметим, что можно (хотя и не рекомендуется в общем случае) использовать заголовок Routing для передачи неглобального адреса через границу связанной зоны в ранее использованном поле следующего адреса. Рассмотрим, например, приём узлом на границе канала (link-border, например, маршрутизатор) пакета с адресом получателя link-local и глобальным адресом отправителя. Если пакет имеет заголовок Routing, где следующим указан глобальный адрес, интерфейс next-hop для глобального адреса может относиться к каналу, отличному от канала для исходного адресата. Это допускается, поскольку область действия следующего адреса не меньше области действия адреса исходного получателя

10. Маршрутизация

Поскольку адреса site-local отменены, а дря адресов link-local не требуется маршрутизация, этот раздел относится лишь к групповой маршрутизации.

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

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

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

                *                                 *
                *                                 *
                *   ===========     Организация X *
                *    |       |                    *
                *    |       |                    *
              +-*----|-------|------+             *
              | *  intf1   intf2    |             *
              | *                   |             *
              | *             intf3 ---           *
              | *                   |             *
              | ***********************************
              |                     |
              |    Маршрутизатор    |
              |                     |
**********************       **********************
              |       *     *       |
Организ. Y  --- intf4  *   *  intf5 --- Организ. Z
              |       *     *       |
**********************       **********************
              +---------------------+

Рисунок . Multicast-маршрутизатор для несколький организаций.

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

Интерфейс 1
- Все глобальные группы.
- Все группы организации, узнанные через интерфейсы 1, 2, 3
Интерфейс 2
- Все глобальные группы.
- Все группы организации, узнанные через интерфейсы 1, 2, 3
Интерфейс 3
- Все глобальные группы.
- Все группы организации, узнанные через интерфейсы 1, 2, 3
Интерфейс 4
- Все глобальные группы.
- Все группы организации, узнанные через интерфейс 4
Интерфейс 5
- Все глобальные группы.
- Все группы организации, узнанные через интерфейс 5

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

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

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

            <address>%<zone_id>

где

<address> — буквальный адрес IPv6;

<zone_id> — строка, указывающая зону адреса;

% — символ-разграничитель между <address> и <zone_id>.

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

11.1. Неглобальные адреса

Формат применим для всех индивидуальных и групповых адресов неглобальной области действия, за исключением незаданного (unspecified) адреса, который не имеет зоны действия. Для глобальных адресов формат не имеет смысла и его не следует применять. Адрес loopback относится к тривиальному каналу, т. е. к каналу, не подключённому к интерфейсу loopback, поэтому формат не следует применять для этого адреса. Данный документ не задаёт использование формата, когда <address> является незаданным адресом (::), поскольку этот адрес не имеет области действия. Однако документ не запрещает использовать формат для специальных адресов, применяемых реализацией.

11.2. Часть <zone_id>

В текстовом представлении следует позволять элементу <zone_id> указание конкретной зоны области действия адреса. Хотя предполагается наличие в индексе зоны сведений, достаточных для определения области действия, и уникальность индекса во всех областях действия (см. раздел), <zone_id> в этом формате не включает область действия. Это связано с тем, что в <address> следует указывать соответствующую область действия. Таким образом, элемент <zone_id> не обязан быть уникальным во всех областях действия. За счёт этого ослабления реализация может использовать удобное ей представление в качестве <zone_id>. Например, для представления индекса канала 2 реализация может просто указать 2 как <zone_id>, что будет удобней других представления, содержащих область link.

При интерпретации формата реализацией следует создавать «полный» индекс зоны, содержащий область действия, по значению <zone_id> и области действия из <address> (в индекс зоны следует включать область действия, как указано в разделе 6).

Реализациям следует поддерживать по меньшей мере числовые индексы в форме неотрицательных целочисленных значений <zone_id>, включая принятый по умолчанию индекс зоны (обычно 0, как указано в разделе 6). Для принятого по умолчанию <zone_id> разграничитель % и значение <zone_id> можно не указывать. Если текстовое представление адреса IPv6 не содержит индекс зоны, его следует интерпретировать как <address>%<default ID>, где <default ID> — принятый по умолчанию индекс зоны для области действия <address>.

Реализация может поддерживать в качестве <zone_id> непустые строки, не содержащие символа-разделителя %. Формат и семантика таких строк определяются реализацией. Одним из возможных вариантов является использование имён интерфейсов, если они не вызывают неоднозначностей для какой-либо области действия. В частности, имена интерфейсов могут служить принятыми по умолчанию идентификаторами для интерфейсов и каналов, поскольку по умолчанию имеется взаимно-однозначное соответствие между интерфейсами и каждой из областей действия, как указано в разделе 6.

Реализация может также использовать имена интерфейсов в <zone_id> для областей больше канала, но в этом случае могут возникать конфликты. Например, при нескольких интерфейсах одного (multicast) сайта у пользователя может возникать путаница с выбором интерфейса. Функция сопоставления адресов с именами столкнётся с той же проблемой при выводе адреса с именем интерфейса в качестве индекса зоны. В документе не заданы способы разрешения таких конфликтов, поскольку они зависят от реализации.

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

11.3. Примеры

Приведённые ниже адреса:

             fe80::1234 (на первом канале узла)
             ff02::5678 (на пятом канале узла)
             ff08::9abc (на десятой организации узла)

будут представлены в виде:

             fe80::1234%1
             ff02::5678%5
             ff08::9abc%10

(здесь предполагается естественный перевод индекса зоны в <zone_id>, где N-я зона любой области переводится в N).

При использовании в качестве <zone_id> имён интерфейсов представление будет иметь вид:

            fe80::1234%ne0
            ff02::5678%pvc1.3
            ff08::9abc%interface10

где интерфейс ne0 относится к каналу 1. pvc1.3 — к каналу 5, а interface10 — к десятой организации.

11.4. Примеры использования

Приложения, используемые на конечных хостах (telnet, ftp, ssh) могут не поддерживать явно указание области действия адресов, особенно link-local. Однако опытным пользователям (например, администраторам сети) следует предоставлять таким приложениям даже адреса link-local.

Рассмотрим конкретный пример, где маршрутизатор R1 с несколькими каналами имеет по меньшей мере 2 интерфейса (канала) point-to-point, каждый из которых соединён с другим маршрутизатором (R2 и R3), а на интерфейсах point-to-point имеются лишь адреса link-local. Предположим, что система маршрутизации R2 «зависла» и её нужно перезапустить. В этом случае не будет возможности использовать глобальный адрес R2 и даже не будет маршрутов для доступа к R2 по причине проблем в маршрутизации. Поэтому потребуется сначала войти (login) в систему R1, а затем пытаться войти на R2 по адресу link-local. Для этого нужно анать адрес link-local маршрутизатора R2 (например, для telnet). Предположим, что это fe80::2.

Отметим, что нельзя просто ввести команду

            % telnet fe80::2

поскольку R1 имеет несколько каналов и telnet не сможет определить канал, который следует использовать для соединения. Вместо этого нужно ввести команду с адресом и индексом канала

            % telnet fe80::2%3

где 3 после разграничителя % указывает индекс нужного канала point-to-point.

11.5. Интерфейсы API

Расширение пекомендуемого базового API указывает способ обработки формата неглобальных адресов в функциях библиотек, транслирующих имена узлов в адреса и обратно [11].

11.6. Пропуск индекса зоны

Заданный в этом документе формат не предназначен для отмены исходного формата неглобальных адресов (адресов без индекса зоны). Как указано в разделе 6, в некоторых общих случаях с понятием индекса зоны по умолчанию не может возникать неоднозначности в части зоны действия. В таких случаях можно опускать %<zone_id>.

11.7. Комбинации символов-разграничителей

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

В архитектуре адресации IPv6 [1] задан синтаксис префиксов IPv6. Если адресная часть префикса не является глобальной и зоеу действия требуется указать однозначно, в адресной части следует использовать описанный здесь формат. Например, префикс link-local fe80::/64 на втором канале можно представить как

            fe80::%2/64

В этой комбинации важно указывать индекс зоны до размера префикса для разбора формата библиотечной функцией трансляции имён в адреса [11], чтобы можно было сначала отделить адрес с индексом зоны от размера префикса, а затем передать их библиотечной функции.

Предпочтительный формат буквальных адресов IPv6 в URL определён в [12]. При использовании предпочтительного формата для неглобального адреса IPv6 с необходимостью явного указания зоны пользователь может применить описанный здесь формат неглобального адреса с сочетании с предпочтительным форматом. Однако введённый идентификатор URL зачастую передаётся в линию, что может приводить к путанице, если приложение не исключит <zone_id> перед отправкой. Отметим, что от приложений не требуется заботиться о типе используемых адресов и, тем более, о разборе или исключении <zone_id> из адреса.

Формат неглобальных адресов может конфликтовать с синтаксисом URI [13], в котором символ % служит для экранирования (escape). Это потребует, например, указывать <zone_id> для зоны 1 с разграничителем в форме %251. Это также ведёт к невозможности просто скопировать неэкранированный формат из другого источника на вход синтаксического анализатора URI. Кроме того, будут возникать отказы, если анализатор URI не преобразует формат с экранированием до передачи в библиотеку трансляции имён в адреса.

Отмеченные проблемы снижают ценность текстового представления, описанного в этом разделе. Поэтому документ не задаёт способ комбинирования формата неглобальных адресов с предпочтительным форматом буквальных адресов IPv6. Во всех случаях при доступности FQDN рекомендуется применять в URL полные имена, а не адреса IPv6.

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

Адреса с ограниченной областью действия без индекса зоны влияют на безопасность и не могут применяться в некоторых контекстах защиты. Например, адреса link-local не могут служить селекторами трафика в защищённых связях, организуемых IKE², при передаче сообщений IKE через глобальные адреса. Кроме того, адреса link-local без индексов зоны нельзя применять в списках контроля доступа.

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

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

13. Участники работы

Этот документ является результатом работы по нескольким направлениям. Atsushi Onoe сыграл важную роль в одной из работ и внёс значительный вклад в содержание раздела 11 как соавтор отдельного предложения.

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

Полезные комментарии и отклики на этот документ представили многие члены рабочей группы IPv6. В частности, Margaret Wasserman и Bob Hinden привели рабочую группу к согласию в части локальной адресации IPv6. Richard Draves предложил дополнительное правило для обработки заголовков Routing с адресами с ограниченной областью действия. Dave Thaler и Francis Dupont внесли ценные предложения по определению семантики индексов зон с точки зрения API. Pekka Savola очень тщательно проанализировал документ и высказал подробные замечания по серьёзным проблемам. Steve Bellovin, Ted Hardie, Bert Wijnen и Timothy Gleeson проанализировали документ и помогли улучшить его в процессе подготовки к публикации.

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

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

[1] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 3513, April 2003.

[2] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[3] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[4] Conta, A. and S. Deering, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 2463, December 1998.

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

[5] Huitema, C. and B. Carpenter, «Deprecating Site Local Addresses», RFC 3879, September 2004.

[6] Draves, R., «Default Address Selection for Internet Protocol version 6 (IPv6)», RFC 3484, February 2003.

[7] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of Link-Local IPv4 Addresses», Work in Progress³.

[8] Conta, A. and S. Deering, «Generic Packet Tunneling in IPv6 Specification», RFC 2473, December 1998.

[9] Narten, T., Nordmark, E., and W. Simpson, «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461, December 1998.

[10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, «Basic Socket Interface Extensions for IPv6», RFC 3493, February 2003.

[11] Gilligan, R., «Scoped Address Extensions to the IPv6 Basic Socket API», Work in Progress, July 2002.

[12] Hinden, R., Carpenter, B., and L. Masinter, «Format for Literal IPv6 Addresses in URL’s», RFC 2732, December 1999.

[13] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 3986, January 2005.

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

Stephen E. Deering

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

Brian Haberman

Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Road

Laurel, MD 20723-6099

USA

Phone: +1-443-778-1319

EMail: brian@innovationslab.net

Tatuya Jinmei

Corporate Research & Development Center, Toshiba Corporation

1 Komukai Toshiba-cho, Saiwai-ku

Kawasaki-shi, Kanagawa 212-8582

Japan

Phone: +81-44-549-2230

Fax: +81-44-520-1841

EMail: jinmei@isl.rdc.toshiba.co.jp

Erik Nordmark

17 Network Circle

Menlo Park, CA 94025

USA

Phone: +1 650 786 2921

Fax: +1 650 786 5896

EMail: Erik.Nordmark@sun.com

Brian D. Zill

Microsoft Research

One Microsoft Way

Redmond, WA 98052-6399

USA

Phone: +1-425-703-3568

Fax: +1-425-936-7329

EMail: bzill@microsoft.com

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

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

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

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

nmalykh@protokols.ru

1Management Information Base — база управляющей информации.

2Internet Key Exchange — обмен ключами в Internet.

3Опубликовано в RFC 3927.