RFC 4291 IP Version 6 Addressing Architecture

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: bob.hinden@nokia.com

Stephen E. Deering

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

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

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

nmalykh@gmail.com

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

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 ietf-ipr@ietf.org.

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

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

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

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

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




RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)

Network Working Group                                           T. Lemon
Request for Comments: 4361                                       Nominum
Updates: 2131, 2132, 3315                                 B. Sommerfield
Category: Standards Track                               Sun Microsystems
                                                           February 2006

Связанные с узлом идентификаторы клиентов для DHCPv4

Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

В этом документе задан формат, который может использоваться для представления идентификаторов клиентов DHCPv41, которые будут взаимозаменяемыми с идентификаторами, используемыми в протоколе DHCPv6. Документ также рещает некоторые проблемы RFC 2131 и RFC 2132 в части обработки идентификаторов клиентов DHCP.

Оглавление

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

1. Введение

Этот документ задает способ, с помощью которого клиентам DHCPv4 [RFC2131] следует идентифицировать себя. Соответствующие данной спецификации клиенты DHCPv4 используют уникальный идентификатор DUID2, как указано в спецификации DHCPv6 [RFC3315]. Значение DUID инкапсулируется в опцию идентификатора клиента DHCPv4 в соответствии с DHCP Options and BOOTP Vendor Extensions [RFC2132]. Описанное здесь поведение заменяет поведение, заданное в RFC2131 и RFC2132.

Причина внесения изменений заключается в том, что в процессе перехода от IPv4 к IPv6 некоторые сетевые устройства должны будут поддерживать сразу DHCPv4 и DHCPv6. Для пользователей таких устройств переход окажется более плавным, нежели в случае, когда устройства идентифицируют себя независимо используемой в данный момент версии DHCP. Наиболее очевидно, что обновления DNS, выполняемые сервером DHCP от имени клиента, будет обрабатываться более корректно. Изменение также решает некоторые проблемы ограничения при использовании идентификаторов клиентов DHCP в стиле RFC 2131/2132.

Документ является первым описанием решаемой проблемы и предлагает новый метод ее решения. Кроме того, описаны изменения, вносимые в RFC 2131 и RFC 2132 для снятия противоречий с данным документом.

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

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

3. Применимость

Этот документ обновляет RFC 2131 и RFC 2132, а также задает поведение, требуемое от клиентов DHCPv4 и DHCPv6, предназначенных для работы в конфигурации с двумя протоколами (dual-stack). Кроме того, документ рекомендует поведение для конфигураций хоста, где для полной настройки требуется последовательная работа нескольких клиентов DHCP (например, использование сетевого загрузчика, а затем загрузка операционной системы).

Клиенты и серверы DHCPv4, реализованные в соответствии с этим документом, должны вести себя так, будто изменения, заданные в параграфах 6.4 и 6.53, внесены в документы RFC 2131 и RFC 2132. Клиентам DHCPv4 дополнительно следует обеспечивать поведение, заданное в параграфе 6.1, а клиентам DHCPv6 — заданное в параграфе 6.2. Серверам DHCPv4 следует обеспечивать поведение, заданное в параграфе 6.3.

4. Постановка задачи

4.1. Непостоянные идентификаторы клиентов

RFC 2132 рекомендует создавать идентификаторы клиентов с использованием постоянного адреса канального уровня на сетевом интерфейсе, который клиент пытается настроить. Результатом этого является смена идентификатора клиента при замене в клиентском компьютере сетевого интерфейса. Клиент потеряет свой адрес IP и другие ресурсы, связанные с прежним идентификатором (например, доменное имя, получаемое от сервера DHCPv4).

4.2. Множество идентификаторов у клиента

Рассмотрим клиента DHCPv4 с двумя сетевыми интерфейсами, одним из которых связан с проводной сетью, второй — с беспроводной. Клиент DHCPv4 может потерпеть полную неудачу, а также настроить один или оба интерфейса. В соответствии с данной спецификацией каждый сетевой интерфейс будет получать свой адрес IP. Сервер DHCPv4 будет считать каждый сетевой интерфейс независимым клиентом DHCPv4 на полностью независимых хостах.

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

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

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

4.3. Несовместимость идентификаторов RFC 2131/2132 и RFC 3315

Опция client identifier используется клиентами и серверами DHCPv4 для обозначения клиентов. В некоторых случаях значение опции client identifier служит для управления доступом к ресурсам (например, для публикации доменного имени клиента через сервер DHCPv4). В RFC 2132 и RFC 3315 заданы разные методы создания идентификатора клиента. Эти методы гарантируют различие идентификаторов DHCPv4 и DHCPv6, что ведет к некорректной работе контроля доступа к ресурсам по идентификатору, если узел может настраиваться иной раз с использованием DHCPv4, другой — с DHCPv6.

4.4. RFC 2131 не требует использовать идентификатора клиента

RFC 2131 позволяет серверам DHCPv4 идентифицировать клиентов с помощью переданной клиентом опции client identifier или адреса канального уровня, если клиент не передал идентификатора. Как и формат идентификатора, рекомендуемый в RFC 2131, это связано с проблемами, описанными в параграфах 4.2 и 4.3.

5. Требования

Для решения проблем, описанных в разделе 4, идентификаторы клиентов DHCPv4 должны обладать перечисленными ниже характеристиками.

  • Постоянство — идентификатор клиента должен сохраняться при удалении или добавлении компонент сетевого оборудования.

  • Клиент должен иметь возможность указать наличие более одного сетевого идентификатора. Например, клиент с двумя сетевыми интерфейсами может указать серверу DHCPv4, что эти два интерфейса должны получить разные адреса IP в случае их подключения к одному каналу.

  • В случае предоставления клиентом DHCPv4 более одного сетевого идентификатора сервер DHCPv4 должен иметь возможность определить их принадлежность одному хосту.

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

  • Серверы DHCPv4, которые не соответствуют данному документу, но соответствуют старой спецификации для идентификаторов клиента, должны корректно обрабатывать идентификаторы, отправленные клиентами, которые соответствуют данной спецификации.

  • Серверы DHCPv4, соответствующие данной спецификации, должны корректно взаимодействовать с не соответствующими этом спецификации клиентами DHCPv4, за исключением того, что могут возникать проблемы, описанные в параграфе 4.25.

  • Использование клиентами DHCPv4 поля chaddr в пакетах DHCPv4 в качестве идентификатора должно быть прекращено.

  • Идентификаторы клиентов DHCPv4 на хостах с двойным стеком, которые используют также DHCPv6, должны указывать одну строку идентификации для DHCPv4 и DHCPv6. Например, сервер DHCPv4, использующий идентификатор клиента для обновления DNS от имени клиента DHCPv4, должен указывать этот же идентификатор клиента в DNS при регистрации через сервер DHCPv6 клиента DHCPv6 на том же хосте и наоборот.

Для выполнения всех этих требований (кроме последнего) нужно создать идентификатор клиента DHCPv4 из двух частей. Одна часть должна быть уникальной для хоста, а другая должна представлять собой уникальный сетевой идентификатор. Этим условиям удовлетворяют уникальный идентификатор DHCP (DUID) и идентификатор отождествления ассоциации (IAID6), заданные в RFC 3315.

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

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

6. Реализация

Здесь описаны изменения в поведении клиентов и серверов DHCPv4, а также указаны изменения по сравнению с RFC 2131 и RFC 2132. Клиенты, серверы и ретрансляторы DHCPv4, соответствующие данной спецификации, должны выполнять RFC 2131 и RFC 2132 с учетом изменений, указанных в параграфах 6.4 и 6.57.

6.1. Поведение клиента DHCPv4

Соответствующие спецификации клиенты DHCPv4 должны использовать стабильные идентификаторы узла DHCPv4 в опции dhcp-client-identifier. Клиентам DHCPv4 недопустимо использовать идентификаторы, основанные лишь на адресах канального уровня, жестко заданных в оборудовании (например, Ethernet MAC), как предложено в RFC 2131 за исключением случаев, разрешенных параграфом 9.2 в RFC 3315. Клиенты DHCPv4 должны передавать опцию client identifier с уникальным идентификатором IAID, как указано в разделе 10 RFC 3315 и DUID, определенным в разделе 9 RFC 3315. Вместе они образуют идентификатор привязки в стиле RFC 3315.

Базовый формат опции DHCPv4 client identifier определен в параграфе 9.14 RFC 2132.

Для передачи идентификатора привязки стиля RFC 3315 в опции DHCPv4 client identifier в поле типа опции client identifier указывается 255. За полем типа сразу следует 32-битовое (не анализируемое) значение IAID, а за ним — значение DUID, занимающее оставшуюся часть опции client identifier.

       Code  Len  Type  IAID                DUID
       +----+----+-----+----+----+----+----+----+----+---
       | 61 | n  | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
       +----+----+-----+----+----+----+----+----+----+---

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

Клиентам DHCPv4 с несколькими сетевыми интерфейсами следует использовать одно значение DUID для всех интерфейсов, при этом значения IAID следует делать разными.

Клиент DHCPv4, создающий значением DUID и имеющий стабильное хранилище, должен сохранять это значение для использования в последующих сообщениях DHCPv4 даже после перезагрузки.

6.2. Поведение клиента DHCPv6

Любому клиенту DHCPv6, соответствующему этой спецификации, следует обеспечивать способ, с помощью которого оператор может узнать выбранное клиентом значение DUID. Таким клиентам следует предоставлять оператору возможность настроить DUID. Устройствам, на которых обычно настроена оба клиента DHCPv4 и DHCPv6, следует автоматически использовать одно значение DUID для DHCPv4 и DHCPv6 без участия оператора.

6.3. Поведение сервера DHCPv4

Этот документ не требует менять поведение серверов DHCPv4 или DHCPv6, соответствующих RFC 2131 и RFC 2132. Однако некоторые серверы DHCPv4 могут быть настроены с отклонением от RFC 2131 и RFC 2132 в том смысле, что они будут игнорировать опцию client identifier и использовать вместо нее аппаратный адрес клиента.

Соответствующие этой спецификации серверы DHCPv4 должны использовать для идентификации клиента опцию client identifier, если клиент передает ее.

Серверы DHCPv4 могут использовать предоставленные администратором значения chaddr и htype для идентификации клиента, если администратор выделил клиенту фиксированный адрес IP, даже при указании клиентом опции client identifier. Это разрешено лишь в том случае, когда администратор сервера DHCPv4 предоставил значения для chaddr и htype, поскольку в такой ситуации при возникновении проблем администратор может исправить дело, удалив неверную информацию.

6.4. Изменения в RFC 2131

В разделе 2 RFC 2131 на странице 98 удаляется текст «это поле может содержать, например, аппаратный адрес, идентичный содержимому поля chaddr, или быть идентификатором другого типа (скажем, именем DNS)».

В параграфе 4.2 RFC 2131 текст «Клиент может явно предоставлять идентификатор в опции client identifier. В таких случаях клиент должен указывать этот же идентификатор во всех последующих сообщениях, а сервер должен использовать это значение для идентификации клиента. Если клиент не использует опцию client identifier, сервер должен использовать для идентификации клиента содержимое поля chaddr» заменяется словами «Клиент должен явно предоставить свой идентификатор с помощью опции client identifier. Клиент должен использовать одинаковую опцию client identifier во всех сообщениях».

В том же параграфе текст «Использование chaddr в качестве идентификатора клиента может приводить к неожиданным результатам, поскольку этот идентификатор может быть связан с аппаратным интерфейсом, который может перейти к другому клиенту. Некоторые сайты могут использовать в качестве client identifier серийный номер оборудования для предотвращения неожиданного изменения сетевого адреса клиента при переносе интерфейса в другой компьютер. В качестве client identifier может использоваться имя DNS для привязки аренды к имени, а не к оборудованию» заменяется текстом «Клиенту DHCP недопустимо опираться на поле chaddr для идентификации».

В параграфе 4.4.1 RFC 2131 текст «Клиент может включить в поле client identifier другой уникальный идентификатор» заменяется тестом «Клиент должен включить уникальный идентификатор».

В параграфе 3.1, пп. 4 и 6, параграфе 3.2 пп. 3 и 4, параграфе 4.3.1, где в RFC 2131 сказано, что chaddr можно использовать вместо опции client identifier, текст «или chaddr» и «chaddr или» удален.

Отметим, что внесенные изменения не отменяют обязанность сервера DHCPv4 использовать chaddr в качестве идентификатора, если клиент не передал опцию client identifier. Скорее они обязывают клиента, соответствующего данному документу, передавать опцию client identifier, не опираясь на chaddrдля идентификации. Серверы DHCPv4 должны использовать chaddr в качестве идентификатора в тех случаях, когда опция client identifier не была передана, для поддержки старых клиентов, которые не соответствуют этому документу.

6.5. Изменения в RFC 2132

В параграфе 9.14 абзац, начинающийся с «Идентификатор клиента может содержать» и следующий за ним абзац заменяются текстом «Идентификатор клиента состоит из поля типа, которое обычно имеет значение 255, за которым следует 4-байтовое поле IA_ID, а затем значение DUID для клиента в соответствии с определением раздела 9 в RFC 3315». Текст «, а минимальный размер составляет 2 октета» из следующего абзаца удаляется.

7. Клиенты DHCP при многоэтапной загрузке из сети

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

Результатом этого для протокола DHCPv4 будет представление разных идентификаторов на двух (иногда и больше) этапах загрузки. Сервер DHCPv4 при этом будет выделять для разных этапов загрузки разные адреса IP.

Некоторые серверы DHCP решают эту проблему для общего случая, когда в памяти PROM9 не присутствует идентификатора клиента а клиент DHCP в операционной системе представляет идентификатор на основе аппаратного (MAC10) адреса сетевого интерфейса, трактуя оба случая как один идентификатор. Это предотвращает выделение двух адресов IP.

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

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

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

Во-вторых, разработчикам клиентов DHCPv4, которые предполагается использовать только в конфигурации с многоэтапной загрузкой, где не предполагается сетевая загрузка с использованием DHCPv6 и MAC-адрес не может быть легко изменен, может не потребоваться реализация изменений, внесенных данной спецификацией. Такое допущение таит в себе некоторые опасности и первое предложение значительно лучше. Компромиссным решением может быть детектирование клиентом DHCP финальной стадии работы на устаревшем (унаследованном) оборудовании и использование в этом случае второго предложения, а в остальных — первого.

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

Этот документ не создает новых проблем безопасности. Возможность атак на протокол DHCPv4 рассмотрена в разделе 7 спецификации протокола DHCP [RFC2131] и документе «Authentication for DHCP Messages» [RFC3118]. Возможность атак на DHCPv6 рассмотрена в разделе 23 RFC 3315.

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

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

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

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, July 2003.

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

[RFC3118] Droms, R. and W. Arbaugh, «Authentication for DHCP Messages», RFC 3118, June 2001.

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

Ted Lemon

Nominum

2385 Bay Road

Redwood City, CA 94063 USA

Phone: +1 650 381 6000

EMail: mellon@nominum.com

Bill Sommerfeld

Sun Microsystems

1 Network Drive

Burlington, MA 01824

Phone: +1 781 442 3458

EMail: sommerfeld@sun.com


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

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

nmalykh@gmail.com

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

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 ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IASA11.

1Dynamic Host Configuration Protocol Version Four — протокол динамической настройки конфигурации хоста, версия 4.

2DHCP Unique Identifier.

3В оригинале ошибочно указаны параграфы 6.3 и 6.4. См. https://www.rfc-editor.org/errata/eid5424. Прим. перев.

4Pre-Boot Execution Environment — среда исполнения до загрузки.

5В оригинале ошибочно указан раздел 2. См. https://www.rfc-editor.org/errata/eid5425. Прим. перев.

6Identity Association Identifier.

7В оригинале ошибочно указаны параграфы 6.3 и 6.4. См. https://www.rfc-editor.org/errata/eid5426. Прим. перев.

8В переводе на сайте www.protocols.ru этот текст расположен на стр. 6. Прим. перев.

9Programmable Read Only Memory — программируемое постоянное запоминающее устройство.

10В оригинале ошибочно указан код аутентификации сообщения (https://www.rfc-editor.org/errata/eid3954). Прим. перев.

11IETF Administrative Support Activity.




RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)

Network Working Group                                           E. Rosen
Request for Comments: 4364                           Cisco Systems, Inc.
Obsoletes: 2547                                               Y. Rekhter
Category: Standards Track                         Juniper Networks, Inc.
                                                           February 2006

BGP/MPLS IP Virtual Private Networks (VPNs)

Виртуальные частные сети IP (VPN) BGP/MPLS

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ описывает метод, с помощью которого сервис-провайдер (SP1) может использовать опорную сеть IP для предоставления своим абонентам услуг виртуальных частых сетей IP VPN2. Метод использует «партнерскую модель», в которой краевые маршрутизаторы абонента (CE3) передают свои маршруты краевым маршрутизаторам SP (PE4). Здесь нет «наложения», видимого для абонентских алгоритмов маршрутизации и маршрутизаторы CE на разных сайтах не имеют партнерских отношений. Пакеты данных туннелируются через опорную сеть так, что маршрутизаторам ядра не нужно знать маршруты VPN.

Этот документ отменяет RFC 2547.

Оглавление

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

1. Введение

Этот документ описывает метод, с помощью которого сервис-провайдер (SP) может использовать опорную сеть IP для предоставления своим абонентам услуг виртуальных частых сетей IP VPN. Метод использует «партнерскую модель», в которой краевые маршрутизаторы абонента (CE) передают свои маршруты краевым маршрутизаторам SP (PE). Сервис-провайдер использует протокол BGP5 [BGP, BGP-MP] для обмена маршрутами конкретной сети VPN между маршрутизаторами PE, подключенными к VPN. Способ обмена гарантирует, что маршруты из разных VPN остаются изолированными, даже если адресные пространства VPN перекрываются. Маршрутизаторы PE распространяют маршрутизаторам CE в определенной VPN маршруты от других CE той же сети VPN. Маршрутизаторы CE не являются партнерами, поэтому здесь не возникает «наложения» видимого алгоритму маршрутизации VPN. Термин IP в «IP VPN» используется для индикации того, что PE получает дейтаграммы IP от CE, проверяет в них заголовки IP и соответствующим образом маршрутизирует.

Каждому маршруту в VPN назначается метка MPLS6 [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS]. При распространении протоколом BGP маршрута VPN вместе с ним распространяется и метка MPLS. До того, как абонентский пакет данных попадет в опорную сеть SP, он инкапсулируется с меткой MPLS, которая соответствует абонетской VPN для маршрута, наиболее точно соответствующего адресу получателя пакета. Затем пакет MPLS инкапсулируется еще раз (например, с другой меткой MPLS или в заголовок туннеля IP или GRE7 [MPLS-in-IP-GRE]), чтобы его можно было туннелировать через опорную сеть нужному маршрутизатору PE. Поэтому маршрутизаторам ядра SP не нужно знать маршруты VPN.

Основной целью этого метода является поддержка случаев, когда абонент получает обслуживание в IP-магистрали от одного или нескольких SP, с которыми у него имеются контрактные отношения. Клиентами могут быть предприятия, группы предприятий, которым нужны услуги extranet, поставщики услуг Internet (ISP8), поставщики услуг приложений, другие провайдеры VPN, использующие такой же метод для предоставления VPN своим клиентам и т. д. Метод обеспечивает клиентам простоту использования услуг опорной сети. Метод обеспечивает расширяемость и гибкость для SP, а также позволяет им предлагать дополнительные услуги.

1.1. Виртуальные частные сети

Рассмотрим множество «сайтов», подключенных к общей сети, которую будет называть опорной или магистральной (backbone). Применим некое правило для создания набора подмножеств в этом множестве и введем правило, в соответствии с которым два сайта могут быть связаны по протоколу IP через магистральную сеть, если хотя бы одно из подмножеств включает оба сайта.

Эти подмножества будут сетями VPN. Два сайта имеют IP-связность через общую опорную сеть лишь в том случае, когда они входят в одну сеть VPN. Два сайта, не входящие в одну сеть VPN, не будут иметь связности через опорную сеть.

Если все сайты в VPN относятся к одному предприятию, VPN можно рассматривать как корпоративную сеть intranet. Если сайты VPN относятся к разным предприятиям, VPN можно считать сетью extranet. Сайт может входить в несколько VPN, например, в корпоративную сеть и несколько сетей extranet. В общем случае термин VPN здесь используется без разделения сетей на intranet и extranet.

Вледельцев сайтов будет называть абонентами (customer), а владельце (операторов) опорных сетей — сервис-провайдерами (SP). Абоненты получают «услуги VPN» от SP.

Абонентом может быть отдельная организация, группа организаций, ISP, провайдер приложений, другой SP, предлагающий услуги VPN своим абонентам и т. п.

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

Описанные в этом документе механизмы позволяют множество вариантов политики. Например, в рамках данной VPN можно разрешить каждому сайту прямой маршрут к каждому из других сайтов (полная связность — full mesh). А можно потребовать маршрутизации трафика между парой сайтов через третий сайт. Это может быть полезно, например, для пропускания трафика через межсетевой экран, расположенный на третьем сайте.

В этом документе рассмотрение ограничено случаем, когда абонент явно покупает услуги VPN у SP или группы SP, которые готовы предоставлять услуги совместно. Т. е. абонент не просто покупает у SP услуги доступа в Intermet, самостоятельно организуя VPN через множество соединенных между собой сетей SP, а покупает «сквозной» сервис.

Рассмотрение также ограничено ситуациями, где абонентам предоставляются услуги магистральной сети IP, а не сервис L2, такой как Frame Relay, ATM9, Ethernet, HDLC10 или PPP11. Абонент может подключаться к магистрали с использованием этих (или иных) услуг L2, но этот сервис завершается на «краю» магистральной сети, где абонентские дейтаграммы IP извлекаются из той или иной инкапсуляции L2.

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

1.2. Периметр абонента и периметр провайдера

Маршрутизаторы могут быть подключены один к другому или к конечным системам разными способами — соединения PPP, виртуальные устройства ATM (VC12) или Frame Relay, интерфейсы Ethernet, виртуальные ЛВС (VLAN13) на интерфейсах Ethernet, туннели GRE, L2TP14 или IPsec и т. п. Термин «устройство присоединения» будет обозначать в общем случае любое из таких соединений. Устройством подключения может быть каналом данных или тем или иным туннелем, позволяющим двум устройствам организовать партнерские отношения на сетевом уровне.

Каждый сайт VPN должен содержать хотя бы одно абонентское краевое устройство (CE15). Каждое устройство CE через то или иное устройство (канал) присоединения подключено к одному или нескольким краевым маршрутизаторам провайдера (PE16).

Маршрутизаторы в сети SP, не соединенные с устройствами CE, называют провайдерскими (P) маршрутизаторами.

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

Иногда физически подключенным к маршрутизатору PE устройством является коммутатор L2. В таких случаях мы не называем этот коммутатор устройством CE. Устройствами CE в этом случае будут хосты и маршрутизаторы, взаимодействующие с маршрутизатором PE через такой коммутатор, поскольку инфраструктура уровня 2 прозрачна. Если эта инфраструктура обеспечивает многоточечный сервис, к маршрутизатору PE может быть подключено множество CE через одно устройство присоединения.

Устройства CE логически являются частью абонентской сети VPN, а маршрутизаторы PE и P — частью сети SP.

Устройство присоединения, через которое пакеты проходят от CE к PE, называют «входным устройством присоединения» (ingress attachment circuit) для пакета, а маршрутизатор PE называют «входным PE» для пакета. Устройство присоединения, через которое пакеты проходят от PE к CE называют «выходным устройством присоединения» (egress attachment circuit) для пакетов, а маршрутизатор PE — «выходным PE» для пакета.

Будем говорить, что маршрутизатор PE подключен к определенной сети VPN, если он подключен к устройству CE, расположенному на сайте этой сети VPN. Аналогично, будем называть PE подключенным к определенному сайту, если он подключен к CE на этом сайте.

Когда CE является маршрутизатором, это устройство будет партнером маршрутизатора (маршрутизаторов) PE, к которому оно подключено, но не будет пратнером маршрутизаторов CE на других сайтах. Маршрутизаторы разных сайтов не обмениваются напрямую маршрутными данными и им даже не нужно знать о существовании друг друга. В результате абоненту не нужно управлять опорной сетью или «виртуальной магистралью» и решать вопросы маршрутизации между сайтами. Иными словами, VPN не является «наложенной» на сеть SP.

В части управления граничными устройствами поддерживаются четкие административные границы между SP и его заказчиками. Абонентам не нужен доступ к маршрутизаторам PE и P для управления ими, а SP не требуется доступ для управления устройствами CE.

1.3. VPN с перекрывающимися адресами

Если две сети VPN не имеют общих сайтов, они могут использовать перекрывающиеся пространства адресов. Т. Е данный адрес может служить в VPN V1 адресом системы S1, а в VPN V2 — адресом совершенно другой системы S2. Это обычная ситуация при использовании в нескольких VPN адресов из приватных блоков RFC 1918. В каждой сети VPN адреса, естественно, должны быть однозначными.

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

1.4. VPN с разными маршрутами в одну систему

Хотя сайт может быть во множестве VPN, не требуется, чтобы маршрут к данной системе на данном сайте был одинаковым во всех этих VPN. Предположим, например, сеть intranet, состоящую из сайтов A, B, C, и сеть extranet из сайтов A, B, C и «чужого» сайта D. Предположим, что на сайте A размещаются серверы, к которым мы хотим предоставить доступ клиентам с сайтов B, C, D. Пусть сайт B служит межсетевым экраном и мы хотим, чтобы весь трафик с сайта D на серверы проходил через межсетевой экран с целью контроля доступа из extranet. Однако трафик с сайта C не нужно пропускать через межсетевой экран, поскольку этот сайт является внутренним.

Можно организовать два маршрута к серверу. Один маршрут (для сайтов B и C) будет направлять трафик напрямую в A. Второй маршрут (для D) будет направлять трафик на межсетевой экран. Если межсетевой экран пропустит трафик, он будет выглядеть как трафик сайта B и попадет по первому маршруту на сайт A.

1.5. Магистральные маршрутизаторы SP

Магистраль SP состоит из PE, а также других маршрутизаторов (P), которые не соединены с устройствами CE.

Если каждый маршрутизатор в магистрали SP будет поддерживать маршрутные данные для всех VPN сервис-провайдера, это приведет к сложностям при расширении, поскольку число поддерживаемых SP сайтов будет ограничиваться объемом маршрутной информации, которую способен хранить один маршрутизатор. Поэтому важно, чтобы маршрутная информация об отдельной VPN была представлена лишь на маршрутизаторах PE, служащих для подключения этой VPN. В частности, маршрутизаторам P не нужна вся информация для каждой VPN (ситуация может меняться при рассмотрении групповой маршрутизации, подробно рассмотренной в [VPN-MCAST].)

Поскольку владельцам VPN не приходится администрировать магистраль или «виртуальную магистраль», SP не выделяет таких магистралей для сетей VPN. Маршрутизация между сайтами в магистрали выполняется оптимально (с ограничениями в политике, применяемыми для формирования VPN) и не ограничивается искусственной «виртуальной топологией» туннелей.

В разделе 10 рассмотрены некоторые специальные вопросы, связанные с работой через несколько SP.

1.6. Безопасность

Описываемые здесь решения VPN даже без криптографической защиты предназначены для обеспечения уровня безопасности, эквивалентного работе на основе магистралей L2 (например, Frame Relay). Т. е. при отсутствии ошибок в конфигурации и преднамеренного соединения между разными VPN системы одной сети VPN не могут получить доступа к системам другой VPN. Описанные здесь методы не шифруют данные для обеспечения конфиденциальности и не поддерживают способов обнаружения перехвата данных в пути. Если это требуется, можно воспользоваться криптографическими мерами (см., например, [MPLS/BGP-IPsec]). Вопросам безопасности посвящено раздел 13.

2. Сайты и CE

С точки зрения отдельной магистральной сети множество IP-систем можно считать сайтом, если эти системы имеют связность IP, не требующую использования магистрали. В общем случае сайт будет состоять из набора систем, которые находятся географически близко. Однако это верно не всегда. Если две географических точки соединены арендованной линией, на которой работает протокол OSPF17 [OSPFv2], и эта линия является предпочтительным способом связи между двумя точками, эти точки можно считать одним сайтом даже при наличии в каждой из них своего маршрутизатора CE. Такое толкование сайта является скорей топологическим, нежели географическим. Если арендованный канал перестанет работать или не будет предпочтительным путем, но две точки продолжат взаимодействие с использованием магистрали VPN, сайт разделится на два сайта.

Устройство CE всегда относится к одному сайту (хотя в параграфе 3.2, сказано, что сайт может состоять из множества «виртуальных сайтов»). Однако сайт может относиться к нескольким VPN.

Маршрутизатор PE может подключаться к устройствам CE любого множества разных сайтов в одной или множестве VPN. Устройство CE для надежности может подключаться к нескольким маршрутизаторам PE одного или разных сервис-провайдеров. Если CE является маршрутизатором, PE и CE будут смежными маршрутизаторами.

Хотя мы в основном считаем сайт базовым блоком взаимодействия, ничто не мешает рассматривать сайты более детально для управления связностью между ними. Например, некоторые системы на сайте могут относиться к внутренней сети (intranet), а также входить в одну или несколько внешний сетей (extranet), тогда как другие входят лишь во внутреннюю сеть. Это может потребовать наличия на сайте двух устройств присоединения к магистрали (одно для intranet, другое для extranet), а также организации межсетевого экрана для устройства присоединения extranet.

3. VRF — множество таблиц пересылки в PE

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

3.1. VRF и устройства подключения

Каждое устройство присоединения PE/CE связано конфигурацией с одной или множеством таблиц VRF. Такие устройства называют устройствами присоединения VRF (VRF attachment circuit).

В простейшем и наиболее распространенном случае устройство присоединения PE/CE связывается с единственной таблицей VRF. Когда пакет IP принимается через определенное устройство присоединения, адрес получателя IP для него отыскивается в связанной таблице VRF. Результат этого поиска определяет маршрутизацию пакета. VRF, используемая входным PE для маршрутизации определенного пакета, называется входной VRF (для пакета имеется и выходная таблица VRF, размещающаяся на выходном PE, как описано в разделе 5).

Если пакет IP приходит через устройство подключения, не связанное с VRF, адрес его получателя отыскивается в принятой по умолчанию таблице пересылки и пакет маршрутизируется в соответствии с ней. Пакеты, маршрутизируемые в соответствии с принятой по умолчанию таблицей, включают пакеты от соседних маршрутизаторов P и PE, а также от обращенных к абонентам устройств присоединения, не связанных с VRF.

Интуитивно можно догадаться, что принятая по умолчанию таблица пересылки является «публичной», а таблицы VRF содержат «приватные» маршруты. Аналогично можно рассматривать устройства присоединения VRF как приватные, а не связанные с VRF устройства присоединения — как публичные.

Если определенное устройство подключения VRF соединяет сайт S с маршрутизатором PE, связность для S (через устройство подключения) может ограничиваться контролируемым набором маршрутов, заданным в соответствующей VRF. Набор маршрутов в этой VRF следует ограничивать маршрутами, ведущими к остальным сайтам VPN, в которую входит S. Когда пакет передается из S через устройство присоединения VRF, он может маршрутизироваться PE на другой сайт S’, если этот сайт относится к одной сети VPN с сайтом S. Т. е. предотвращается взаимодействие (через PE) между сайтами, не входящими в одну VPN. Коммуникации между сайтами VPN и не входящими в VPN сайтами также пресекаются, поскольку маршруты к сайтам VPN не включаются в принятую по умолчанию таблицу пересылки.

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

Возможно связывание одного устройства присоединения с множеством VRF. Это может быть полезно в тех случаях, когда нужно разделить VPN на несколько суб-VPN, для каждой из которых устанавливаются свои ограничения связности, а выбор между суб-VPN выполняется на основе тех или иных характеристик пакетов. Здесь для простоты всегда предполагается, что устройство присоединения связано с единственной таблицей VRF.

3.2. Связывание пакетов IP с VRF

Когда маршрутизатор PE получает пакет от устройства CE, он должен определить через какое устройство присоединения поступил пакет, поскольку это нужно для выбора таблицы VRF (или набора VRF), которая будет применяться для пересылки пакета. В общем случае для определения доставившего пакет устройства присоединения PE отмечает физический интерфейс, принявший пакет, и может также отмечать некоторые аспекты заголовка L2 в пакете. Например, если входным устройством присоединения для пакета служит Frame Relay VC, отождествление устройства присоединения может быть выполнено по физическому интерфейсу Frame Relay и полю DLCI19 в заголовке Frame Relay.

Хотя заключение PE о прибытии пакета через определенное устройство подключения может частично определяться заголовком L2 в пакете, у абонента не должно быть возможности ввести провайдера в заблуждение путем создания специальных заголовков L2 с целью привязки пакета к другому устройству присоединения. В приведенном выше примере устройство присоединения частично определяется проверкой поля DLCI в заголовке Frame Relay, которое не может быть установлено абонентом. Это должно быть значение, назначенное SP, поскольку в ином случае пакет просто не попадет в маршрутизатор PE.

В некоторых случаях абонент может делить сайт на несколько «виртуальных сайтов». SP может обозначить определенный набор таблиц VRF, используемых для маршрутизации пакетов с такого сайта, и позволить абоненту устанавливать некоторые характеристики пакетов, которые позволят выбрать нужную таблицу VRF из этого набора.

Например, каждый виртуальный сайт может быть реализован в форме VLAN, а SP и абонент могут договориться, что пакеты, приходящие из определенного CE, содержат значения VLAN, которые будут применяться для идентификации некоторых VRF. Пакеты от этого CE будут отбрасываться устройством PE, если в них будут указаны несогласованные теги VLAN. Другим способом решения задачи является использование IP-адресов отправителей. В этом случае PE использует адреса отправителей в пакетах, полученных от CE, вместе с принявшим пакет интерфейсом для привязки пакета к определенной таблице VRF. И снова абоненту предоставляется лишь выбор из определенного набора VRF, разрешенного для этого абонента.

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

3.3. Заполнение VRF

Какими маршрутами заполняются таблицы VRF?

Рассмотрим пример с тремя маршрутизаторами PE (PE1, PE2, PE3) и тремя маршрутизаторами CE (CE1, CE2, CE3). Предположим, что PE1 узнает от CE1 маршруты, доступные на сайте CE1. Если PE2 и PE3 подключены к CE2 и CE3, соответственно, и имеется VPN V, включающая CE1, CE2 и CE3, маршрутизатор PE1 использует BGP для распространения маршрутизаторам PE2 и PE3 маршрутов, полученных от CE1. PE2 и PE3 используют эти маршруты для заполнения своих таблиц VRF, которые связаны с сайтами CE2 и CE3 соответственно. Маршруты от сайтов, не входящих в VPN V, не будут присутствовать в этих VRF, в результате чего пакеты от CE2 и CE3 не могут быть переданы на сайты, не входящие в VPN V.

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

Маршрутизаторам PE нужно также узнать от других PE маршруты, относящиеся к данной сети VPN. Процедуры, используемые для заполнения таблиц VRF нужными маршрутами, описаны в разделе 4.

При наличии множества устройств присоединения между маршрутизатором PE и определенным сайтом эти устройства могут отображаться на одну таблицу пересылки. Но политика может требовать отображения таких устройств на разные таблицы. Например, в соответствии с политикой определенное устройство подключения можно использовать лишь для внутреннего трафика (intranet), а другое — только для extranet (это может быть связано с наличием межсетевого экрана на CE, подключенном к extranet). В этом случае два устройства присоединения будут связаны с разными VRF.

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

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

4. Распространение маршрутов VPN по протоколу BGP

Маршрутизаторы PE используют BGP для распространения маршрутов VPN между собой.

Каждая сеть VPN может использовать свое адресное пространство, поэтому определенный адрес может указывать разные системы в разных VPN. Если два маршрута к одному адресному префиксу IP являются маршрутами в разные системы, важно обеспечить, чтобы протокол BGP не считал эти маршруты сравнимыми. Иначе BGP может выбрать лишь один из таких маршрутов, сделав другую систему недоступной. Кроме того, нужно убедиться, что политика применяется для определения маршрутов, по которым нужно отправлять пакеты. С учетом того, что BGP устанавливает несколько маршрутов для одного префикса, в каждой конкретной таблице VRF может присутствовать лишь один такой маршрут.

Для решения этой задачи далее определяется новое семейство адресов.

4.1. Семейство адресов VPN-IPv4

Многопротокольные расширения BGP [BGP-MP] позволяют протоколу BGP передавать маршруты для множества семейств адресов. Здесь вводится новое семейство VPN-IPv4, которое включает 12-байтовое значение, начинающееся с 8-байтового поля RD20 и заканчивающееся 4 байтами адреса IPv4. Если несколько VPN используют один префикс IPv4, маршрутизаторы PE будут транслировать этот префикс в уникальные адресные префиксы VPN-IPv4. Это позволяет применять один и тот же адрес в разных VPN и обеспечивает BGP поддерживать разные маршруты к одинаковым префиксам в разных VPN.

Поскольку адреса VPN-IPv4 и IPv4 относятся к разным семействам, BGP никогда не сравнивает такие адреса.

RD является лишь числом и не содержит какой-либо специальной информации, не указывая источник маршрута или множества VPN, в которые распространяется маршрут. Назначение RD заключается лишь в создании различаемых маршрутов для одинаковых префиксов IPv4. Для определения области распространения маршрута применяются иные средства (параграф 4.3).

RD можно также использовать для создания множества разных маршрутов в одну и ту же систему. Выше уже рассматривалась ситуация, когда маршруты в одну систему должны различаться для трафика intranet и extranet. Это можно обеспечить путем организации двух разных маршрутов VPN-IPv4 с совпадающей частью IPv4, но разными RD. В результате BGP сможет установить множество разных маршрутов в одну систему и позволит применять правила (параграф 4.3.5) для выбора маршрута конкретных пакетов.

Значения RD структурированы так, что каждый SP может администрировать свое собственное «пространство номеров» (т. е. самостоятельно назначать RD) без конфликтов со значениями RD, выделенными другими SP. Значение RD состоит из трех полей — двухбайтовое поле типа, поле администратора и поле назначенного номера. Значение поля типа определяет размеры двух оставшихся полей и семантику поля администратора. Поле administrator указывает выделившую номер организацию, а поле assigned number содержит номер, назначенный этой организацией для определенной цели. Например, можно использовать RD, где в поле администратора будет указан номер автономной системы (ASN21), а (4-байтовое) поле номера будет содержать значение, выделенное SP, которому принадлежит ASN (номера автономных систем выделяются для SP специальными регистраторами).

Структура RD выбрана так, чтобы SP, предоставляющие магистральные услуги VPN, могли создавать уникальные значения RD при возникновении потребности. Однако структура RD не имеет значения в BGP и не принимается во внимание при сравнении адресных префиксов.

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

4.2. Кодирование RD

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

  • поле Type — 2 байта

  • поле Value — 6 байтов

Интерпретация поля Value зависит от значения поля Type. В настоящее время для типа определены значения 0, 1, 2.

  • Type 0 — поле Value состоит из двух субполей:

    • Administrator — 2 байта;

    • Assigned Number — 4 байта.

    Субполе Administrator должно содержать номер автономной системы. Если ASN относится к публичному пространству номеров, его значение должно быть выделено соответствующим регистратором (использование ASN из частного пространства настоятельно не рекомендуется). Субполе Assigned Number содержит значение из пространства номеров, администрируемого владельцем ASN, выделенного регистратором.

  • Type 1 — поле Value состоит из двух субполей:

    • Administrator — 4 байта;

    • Assigned Number — 2 байта.

    Субполе Administrator должно содержать IP-адрес. Если это адрес из публичного пространства IP, он должен быть выделен соответствующим регистратором (использование IP из частных пространство настоятельно не рекомендуется). Субполе Assigned Number содержит значение из пространства номеров, администрируемого владельцем IP-адреса.

  • Type 2 — поле Value состоит из двух субполей:

    • Administrator — 4 байта;

    • Assigned Number — 2 байта.

    Субполе Administrator должно содержать 4-байтовый номер автономной системы [BGP-AS4]. Если ASN относится к публичному пространству номеров, его значение должно быть выделено соответствующим регистратором (использование ASN из частного пространства настоятельно не рекомендуется). Субполе Assigned Number содержит значение из пространства номеров, администрируемого владельцем ASN, выделенного регистратором.

4.3. Контроль распространения маршрутов

В этом параграфе рассматривается способ контроля за распространением маршрутов VPN-IPv4.

Если маршрутизатор PE подключен к некой VPN (будучи подключенным к CE из этой VPN), он узнает некоторые из IP-маршрутов этой VPN от подключенного маршрутизатора CE. Маршруты, полученные от партнерского CE через определенное устройство присоединения, могут быть включены в таблицу VRF, связанную с этим устройством присоединения. Точный выбор устанавливаемых маршрутов определяется способом получения устройством PE маршрутов от CE. В частности, когда PE и CE являются партнерами для протокола маршрутизации, это определяется решением протокола маршрутизации, как описано в разделе 7.

Полученные маршруты преобразуются с маршруты VPN-IP4 и «экспортируются» в BGP. Если для определенного префикса VPN-IP4 имеется несколько маршрутов, BGP выбирает «лучший», используя процесс решения BGP. Этот маршрут затем распространяется по протоколу BGP другим устройствам PE, которые должны его знать. На этих PE протокол BGP снова выбирает лучший маршрут для конкретного префикса VPN-IP4. Затем выбранные маршруты VPN-IP4 конвертируются обратно в маршруты IP и «импортируются» в одну или несколько таблиц VRF. Выбор маршрутов для установки в VRF зависит от процесса решения метода маршрутизации, используемого между PE и теми CE, которые связаны с соответствующей таблицей VRF. В заключение все маршруты, установленные в VRF, могут быть распространены соответствующим устройствам CE.

4.3.1. Атрибут RT

Каждая таблица VRF связана с одним или несколькими атрибутами RT22.

При создании маршрута VPN-IPv4 (из маршрута IPv4, который PE узнал от CE) маршрутизатором PE, с ним связывается один или несколько атрибутов RT, которые передаются BGP как атрибуты маршрута.

Любой маршрут, связанный с RT T, должен распространяться каждому маршрутизатору PE, который имеет VRF, связанную с RT T. При получении такого маршрута устройством PE он может быть выбран для включения в таблицы VRF этого PE, которые связаны с RT T (реальная установка зависит от процесса решения BGP и IGP на интерфейсе PE/CE).

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

Имеется набор атрибутов RT, которые маршрутизатор PE присоединяет к маршруту, полученному от сайта S, его можно назвать «целями экспорта» (Export Target). Имеется также набор атрибутов RT, которые PE использует для решения вопроса о размещении полученных от другого PE маршрутов в таблицу VRF, связанную с сайтом S, их можно назвать «целями импорта» (Import Target). Эти два набора различаются и не должны быть одинаковыми. Отметим, что определенный маршрут VPN-IPv4 может быть выбран для установку в ту или иную таблицу VRF лишь при наличии некого RT одновременно в атрибутах RT этого маршрута и целях импорта VRF.

Функция, выполняемая атрибутом RT, похожа на функцию атрибута BGP Communities. Однако формат последнего не подходит для рассматриваемых здесь задач, поскольку он поддерживает лишь 2-байтовые значения. Желательно структурировать формат подобно формату RD (параграф 4.2), чтобы поле типа определяло размер поля администратора, а оставшаяся часть атрибута включала выделенное администратором числовое значение. Это можно сделать с помощью BGP Extended Communities. Рассматриваемые здесь атрибуты RT кодируются как BGP Extended Community Route Targets [BGP-EXTCOMM] и имеют структуру, подобную RD.

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

Отметим, что маршрут может иметь лишь один идентификатор RD, но множество атрибутов RT. Расширяемость BGP улучшается, если можно использовать один маршрут со множеством атрибутов вместо множества маршрутов. Можно отказаться от атрибутов RT за счет создания множества маршрутов (т. е. применять больше RD), но это ухудшит расширяемость.

PE может определить атрибуты RT для связывания с маршрутом множеством разных способов. Можно настроить на PE привязку всех маршрутов, ведущих на определенный сайт, с конкретным значением RT. Можно настроить на PE привязку некоторых маршрутов, узнанных для заданного сайта к одному RT, а иных — к другому.

Если PE и CE являются партнерами BGP (раздел 7), SP может разрешить абоненту в определенных пределах управлять распространением своих маршрутов. SP и абонент должны заранее согласовать набор RT, которые можно присоединять к маршрутам абонентских VPN. Тогда CE сможет присоединять один или несколько таких атрибутов RT к каждому маршруту IP, который он распространяет PE. Это дает абоненту свободу управлять в реальном масштабе времени правилами распространения своих маршрутов в согласованных рамках. Если маршрутизатору CE разрешено присоединять атрибуты RT к своим маршрутам, PE должен отфильтровывать все маршруты, с неразрешенными для абонента атрибутами RT. Если CE не разрешено присоединять RT к своим маршрутам, но он все равно это делает, PE должен удалять атрибуты RT перед конвертированием абонентского маршрута в VPN-IPv4.

4.3.2. Распространение маршрутов между PE по протоколу BGP

Если два сайта VPN подключены к маршрутизаторам PE в одной автономной системе, эти PE могут обмениваться маршрутами VPN-IPv4 через соединение IBGP между ними (термином IBGP обозначают набор протоколов и процедур, используемых для соединений между двумя узлами BGP в одной AS, а термином EBGP — набор процедур, используемых между двумя узлами BGP в разных AS). В дополнение к этому каждый PE может иметь соединение IBGP с рефлектором маршрутов [BGP-RR].

При распространении маршрутизатором PE маршрутов VPN-IPv4 по протоколу BGP он указывает свой адрес в качестве BGP next hop, указываемый в форме VPN-IPv4 с RD = 0 ([BGP-MP] требует использования для next hop того же семейства адресов, что и NLRI23). Маршрутизатор также назначает и распространяет метку MPLS (важно отметить, что PE распространяют не просто маршруты VPN-IPv4, а Labeled VPN-IPv4 [MPLS-BGP]). Когда PE получает пакет с такой меткой на вершине стека, он выталкивает метку из стека и обрабатывает пакет соответствующим образом.

PE может распространять напрямую маршруты из VRF, объединять маршруты и распространять агрегаты или распространять часть маршрутов напрямую, а другие агрегировать.

Предположим, что PE назначил метку L для маршрута R и распространяет это отображение по протоколу BGP. Если R является агрегатом набора маршрутов из VRF, PE будет знать, для каких пакетов, пришедших из магистрали с такой меткой, нужно искать адреса получателей в VRF. Когда PE выполняет поиск метки в Label Information Base, он узнает какую VRF нужно использовать. С другой стороны, если R не является агрегатом, то при поиске метки в базе PE узнает выходное устройство присоединения, а также заголовок инкапсуляции для пакета. В этом случае поиск в VRF не нужен.

Предполагается, что в большинстве случаев маршруты не будут агрегатами. Агрегированные маршруты могут быть очень полезны, если VRF содержит большре число маршрутов к хостам (например, при доступе по телефонным линиям) или VRF связана с интерфейсом ЛВС, где используется свой заголовок L2 для каждой системы, но маршруты не распространяются в каждую системы.

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

  • Можно выбрать одну метку для таблицы VRF и использовать ее во всех маршрутах. Когда выходной PE получит пакет с такой меткой, он должен будет найти IP-адрес получателя пакета в таблице VRF («выходная VRF» для пакета), чтобы определить выходное устройство подключения и соответствующую инкапсуляцию L2.

  • Можно выбрать одну метку для каждого устройства присоединения, чтобы она применялась на всех маршрутах с одним «выходным устройством подключения». Это позволяет избежать поиска в выходной VRF, хотя тот или иной поиск может потребоваться для определения инкапсуляции L2 (например, поиск ARP24).

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

Возможны и другие алгоритмы и выбор остается за выходным PE.

При таком использовании распространенных по BGP меток MPLS мы предполагаем, что пакет MPLS с такой меткой может быть туннелировать от маршрутизатора, установившего полученный по протоколу BGP маршрут, в маршрутизатор, который служит BGP next hop для этого маршрута. Это требует наличия между этими маршрутизаторами пути с коммутацией по меткам или применения какой-либо иной технологии туннелирования (например, [MPLS-in-IP-GRE]).

Этот туннель может проходить по обычному (best effort) маршруту или следовать маршруту с организацией трафика (traffic-engineered). Между данной парой маршрутизаторов может быть один такой туннель или несколько туннелей с разными характеристиками QoS25. Для архитектуры VPN важно лишь наличие такого туннеля. Для обеспечения взаимодействия между системами, реализующими эту архитектуру VPN с использованием путей с коммутацией по меткам MPLS в качестве технологии туннелирования, эти системы должны поддерживать протокол LDP26 [MPLS-LDP]. В частности, должен поддерживаться режим Downstream Unsolicited на интерфейсах, которые не являются LC-ATM27 [MPLS-ATM] или LC-FR28 [MPLS-FR], и режим Downstream on Demand на интерфейсах LC-ATM и LC-FR.

Если туннель проходит по маршруту best-effort, PE находит маршрут к удаленной точке путем поиска ее IP-адреса в принятой по умолчанию таблице пересылки.

Маршрутизатору PE, пока он не является рефлектором маршрутов (параграф 4.3.3) или граничным маршрутизатором AS (ASBR) для межпровайдерской VPN (раздел 10), не следует устанавливать маршрут VPN-IPv4, если у него нет хотя бы одной VRF с целью импорта, идентичной обному из атрибутов RT в маршруте. Для отбрасывания маршрутов следует применять входную фильтрацию. Если позднее будет добавлена новая цель импорта в обну из таблиц VRF маршрутизатора PE (операция VPN Join), маршрутизатор должен будет принять маршруты, которые ранее могли отбрасываться. Это можно сделать с помощью механизма обновления, описанного в [BGP-RFSH]. Можно также использовать механизм выходной фильтрации [BGP-ORF], чтобы сделать фильтрацию более динамичной.

Аналогично, если конкретная цель импорта больше не присутствует в таблицах VRF маршрутизаторов PE (в результате операций VPN Prune), PE может отбросить все маршруты и в результате не будет иметь каких-либо целей импорта в своих VRF как одного из атрибутов RT.

Маршрутизатор, не подключенный к VPN и не являющийся рефлектором маршрутов (т. е. P) не устанавливает маршрутов VPN-IPv4.

Обметим, что операции VPN Join и VPN Prune не нарушают работу и не требуют разрыва соединений BGP, если используется механизм обновления [BGP-RFSH].

В результате применения этих правил ни одному маршрутизатору PE не требуется поддерживать маршруты во все VPN — это важно для расширяемости.

4.3.3. Использование рефлекторов

Вместо организации полносвязных соединений IBGP между всеми PE, можно воспользоваться рефлекторами маршрутов BGP RR29 [BGP-RR] для более эффективной расширяемости. Доступны все обычные методы использования рефлекторов для улучшения расширяемости (например, иерархии рефлекторов).

Рефлекторы маршрутов являются единственными системами, которым нужна маршрутная информация для VPN, не подключенных непосредственно. Однако не требуется, чтобы какой-либо из рефлекторов знал все маршруты VPN-IPv4 для всех VPN, поддерживаемых в магистральной сети.

Ниже описаны два разных способа разделения маршрутов VPN-IPv4 между двумя наборами рефлекторов.

  1. В каждом рефлекторе заранее настраивается список целей маршрутов (RT). Для резервирования один и тот же список может быть задан в нескольких рефлекторах. Рефлектор применяет заданный список RT для создания входных фильтров маршрутов. Рефлектор может использовать методы [BGP-ORF], чтобы организовать для каждого из своих партнеров (независимо от того, является партнер другим рефлектором или PE) набор выходных фильтров маршрутов (ORF30) содержащий список заранее заданных RT. Отметим, что рефлекторам следует воспринимать фильтры ORF от других рефлекторов, что означает анонсирование возможности поддержки ORF другим рефлекторам.

    Сервис-провайдер может изменить список заранее настроенных RT на рефлекторе. Когда это сделано, рефлектор меняет таблицы ORF, установленные на всех его партнерах IBGP. Для снижения частоты изменения конфигурации на рефлекторах маршрутов в каждом рефлекторе можно заранее настроить блок RT. Таким образом, при возникновении потребности в новом атрибуте RT для новой сети VPN на обном или нескольких рефлекторах уже будет (заранее) заданный в настройке атрибут RT.

    Если данный маршрутизатор PE не является клиентом всех рефлекторов, при добавлении на нем новой сети VPN31 (VPN Join) маршрутизатору нужно будет стать клиентом рефлекторов, которые поддерживают маршруты для этой VPN. Аналогично, удаление имеющейся VPN из PE (VPN Prune) может приводить к ситуации, когда PE уже не нужно быть клиентом некоторых рефлекторов. В любом случае операция Join или Prune не нарушает работу (поскольку используется [BGP-RFSH]) и никогда не требуется прерывать соединение BGP, нужно лишь правильно резервировать его.

  2. Другой метод заключается в том, чтобы каждый маршрутизатор PE был клиентом некоторого подмножества рефлекторов. На рефлекторах не настраивается заранее список RT и не выполняется входной фильтрации маршрутов и принимаются все маршруты от клиентов (PE). Рефлекторы отслеживают набор атрибутов RT во всех принимаемых маршрутах. При получении реафлектором от клиента маршрута с отсутствующим в наборе атрибутом RT, этот атрибут сразу же добавляется в набор. С другой стороны, при отсутствии у рефлектора каких-либо маршрутов с конкретным RT из набора, рефлектору следует задерживать (на несколько часов) удаление RT из набора.

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

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

    Указанная выше задержка в несколько часов позволяет рефлектору удерживать маршруты с данным RT даже после потери своих клиентов, заинтересованных в таких маршрутах. Это избавляет от необходимости заново получать эти маршруты, если «исчезновение» клиента было лишь временным.

    В этой процедуре операции VPN Join и VPN Prune также не нарушают работы.

    Отметим, что этот метод не будет корректно работать, если какой-либо клиент PE имеет таблицу VRF с импортируемым атрибутом RT, который является одним из экспортируемых RT.

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

Как нет ни одного PE, которому требуется знать все маршруты VPN-IPv4, поддерживаемые в магистральной сети, при использовании этих правил гарантированно не будет требоваться и рефлектор маршрутов (RR), которому нужно знать все поддерживаемые в магистральной сети маршруты VPN-IPv4. В результате число таких маршрутов в магистральной сети не ограничивается возможностями одного устройства и поэтому является практически безграничным.

4.3.4. Передача VPN-IPv4 NLRI в BGP

Для кодирования NLRI применяются многопротокольные расширения BGP [BGP-MP]. Если поле AFI32 имеет значение 1, а SAFI33 — 128, поле NLRI будет содержать адрес VPN-IPv4 с меткой MPLS. AFI 1 применяется потому, что протоколом сетевого уровня, связанным с NLRI остается IP. Отметим, что эта архитектура VPN не требует поддержки распространения адресов VPN-IPv4 без меток.

Для того, чтобы два узла BGP могли обмениваться помеченными VPN-IPv4 NLRI, они должны использовать BGP Capabilities Advertisement для подтверждения обработки таких NLRI обеими сторонами. Эта процедура выполняется в соответствии с [BGP-MP] и использует код возможности 1 (multiprotocol BGP) с AFI = 1 и SAFI = 128.

Кодирование VPN-IPv4 NLRI с метками задано в [MPLS-BGP] — префикс содержит 8-байтовое поле RD, за которым следует префикс IPv4.

4.3.5. Построение VPN с использованием RT

Путем установки нужных целей импорта и экспорта можно создавать разные типы VPN.

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

В качестве другого варианта предположим создание VPN типа «звезда» (hub and spoke34). Это можно сделать, применяя два значения RT — одно для Hub, другое для Spoke. Для таблиц VRF, связанных с сайтами-концентраторами, Hub будет целью экспорта, а Spoke — целью импорта. Для VRF, связанных с лучами, целью импорта будет Hub, а целью экспорта — Spoke.

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

4.3.6. Распространение маршрутов между VRF в одном PE

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

5. Пересылка

Если промежуточные маршрутизаторы ничего не знают о маршрутах в сетиVPN, как же пакеты передаются из одной VPN в другую?

Когда маршрутизатор PE получает пакет IP от устройства CE, он выбирает определенную таблицу VRF для поиска адреса получателя пакета. Этот выбор обусловлен входным устройством присоединения, доставившим пакет. Предположим, что адрес найден в таблице. В результате вы узнаем следующий интервал пересылки (next hop).

Если этот интервал доступен напрямую через устройство присоединения VRF с этого PE (т. е. выходное устройство присоединения находится на том же PE, что и входное устройство присоединения), пакет передается в выходное устройство без вталкивания метки MPLS в стек меток пакета.

Если входное и выходное устройства присоединения находятся на одном PE, но связаны с разными таблицами VRF и лучший маршрут для абреса получателя в VRF входного устройства присоединения объединяет несколько маршрутов из VRF выходного устройства присоединения, может потребоваться также поиск адреса получателя в выходной VRF.

Если следующий интервал пересылки (next hop) не доступен через устройство присоединения VRF, пакет должен пройти по меньшей мере один интервал пересылки через магистральную сеть. Пакет, таким образом, имеет интервал пересылки BGP Next Hop, с которым связана метка MPLS для маршрута, лучше всего соответствующего адресу получателя. Эту метку называют «меткой маршрута VPN» (VPN route label). Пакет IP помещается в пакет MPLS с меткой маршрута VPN в качестве единственной метки в стеке.

Затем пакет должен туннелироваться по адресу BGP Next Hop.

Если магистральная сеть поддерживает MPLS, пересылка происходит в соответствии с приведенным ниже описанием.

  • Маршрутизаторы PE (и любые граничные маршрутизаторы AS35), которые распространяют адрес VPN-IPv4, должны добавлять перфикс /32 своего адреса в таблицы маршрутизации IGP магистральной сети. Это позволяет MPLS на каждом узле магистральной сети назначать метку, соответствующую маршруту к каждому PE. Для обеспечения взаимодействия разных реализаций требуется поддержка протокола LDP для организации путей с коммутацией по меткам через магистральную сеть. Однако возможны и другие методы организации таких путей (некоторые из таких методов не требуют наличия адресных префиксов /32 в IGP).

  • При наличии каких-либо туннелей с организацией трафика (traffic engineering) к BGP next hop и доступности одного или нескольких таких туннелей для рассматриваемого пакета выбирается один из этих туннелей. Туннели будут связаны с меткой MPLS (метка туннеля), которая вталкивается в стек меток MPLS и пакет пересылается на следующий интервал туннеля.

  • В остальных случаях выполняются перечисленные ниже действия.

    • Пакет будет иметь IGP Next Hop, указывающий следующий интервал пересылки по маршруту IGP к BGP Next Hop.

    • Если BGP Next Hop и IGP Next Hop совпадают и применяется выталкивание метки на предпоследнем интервале, пакет передается по адресу IGP Next Hop с единственной меткой маршрута VPN.

    • В остальных случаях IGP Next Hop будет иметь метку, назначенную для маршрута, наиболее соответствующего адресу BGP Next Hop. Эту метку называют меткой туннеля и она помещается на вершину стека меток пакета. Затем пакет пересылается по адресу IGP Next Hop.

  • MPLS будет предавать пакет через магистральную сеть по адресу BGP Next Hop, где проверяется метка VPN.

Если магистральная сеть не поддерживает MPLS, пакет MPLS с единственной меткой туннеля VPN может быть туннелирован до BGP Next Hop с использованием методов [MPLS-in-IP-GRE]. Пакет выйдет из туннеля на BGP Next Hop, где метка туннеля VPN будет проверяться.

На BGP Next Hop трактовка пакета зависит от метки маршрута VPN (параграф 4.3.2). Во многих случаях по этой метке PE сможет определить устройство присоединения, через которое следует передать пакет (устройству CE), а также подходящий заголовок канального уровня для этого интерфейса. В других случаях PE сможет определить только адрес получателя, по которому нужно выполнить поиск в соответствующей таблице VRF до пересылки пакета устройству CE. Имеются также промежуточные варианты, в которых метка маршрута VPN может определять выходное устройство присоединения для пакета, но придется выполнять тот или иной поиск (например, ARP) для определения заголовка канального уровня на этом устройстве.

Информация в самом заголовке MPLS и/или информация, связанная с меткой, могут также служить для обеспечения QoS на интерфейсе с устройством CE.

В любом случае прибывший на входное устройство PE пакет IP без метки останется не помеченным и на выходе из выходного устройства PE.

Туннелирование пакетов с метками маршрутов VPN через магистральную сеть позволяет изолировать все маршруты VPN от маршрутизаторов P. Это важно для расширяемости схемы. Магистральной сети не нужно знать и маршрутов к CE, достаточно знать маршруты к PE.

Применительно к туннелям данная спецификация:

  • не требует туннелей «точка-точка» и позволяет применять туннели «множество с одним» (multipoint-to-point);

  • не требует какой-либо явной организации туннелей с помощью протоколов сигнализации или вручную;

  • не требует какой-либо конкретной сигнализации для туннелей;

  • не требует каких-либо связанных с туннелями состояний в маршрутизаторах P или PE кроме тех, которые нужны для поддержки маршрутной информации и меток MPLS, если они применяются.

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

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

6. Поддержка подобающей изоляции VPN

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

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

  1. Верхняя метка в стеке была действительно распространена данным маршрутизатором магистральной сети не относящемуся к магистрали устройству.

  2. Магистральный маршрутизатор может убедиться в том, что использование этой метки будет приводить к выходу пакета из магистральной сети до того, как будут проверены нижележащие метки или заголовок IP.

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

Если MPLS не применяется в качестве технологии туннелирования, фильтрация должна быть организована так, чтобы магистральные маршрутизаторы воспринимали пакеты MPLS-in-IP и MPLS-in-GRE лишь в том случае, когда адрес получателя в них будет вызывать передачу за пределы магистральной сети.

7. Как PE узнают маршруты от CE

Маршрутизаторы PE, подключенные к определенной сети VPN, должны знать для каждого ведущего в VPN устройства присоединения, какие из адресов VPN должны быть доступны через данное устройство присоединения.

PE транслирует эти адреса в адреса VPN-IPv4, используя настроенные идентификаторы RD. Затем эти маршруты VPN-IPv4 устройство PE трактует как входную информацию BGP. Маршруты из сайта VPN не передаются в IGP магистральной сети.

Конкретный метод распространения маршрутов PE/CE зависит от того, находится ли конкретное устройство CE в «транзитной VPN». Транзитной считается сеть VPN, которая содержит маршрутизатор, получающий маршруты от «третьей стороны» (т. е. от маршрутизатора, не входящего в VPN и не являющегося PE) и распространяющий их маршрутизатору PE. VPN, не являющиеся транзитными, называют оконечными VPN (stub VPN). Подавляющее большинство сетей VPN, включая практически все корпоративные сети, в этом смысле являются оконечными.

Возможные методы распространения маршрутов PE/CE перечислены ниже.

  1. Может использоваться статическая маршрутизация (т. е. настройка). Очевидно, что это подходит лишь для оконечных VPN.

  2. Маршрутизаторы PE и CE могут быть партнерами RIP36 [RIP] и CE может использовать RIP для информирования PE о наборе адресных префиксов, доступных на сайте CE. При настройке RIP на CE следует принять меры, чтобы префиксы других сайтов (т. е. префиксы, полученные CE от маршрутизатора PE) никогда не анонсировались PE. Точнее говоря, если маршрутизатор PE (скажем, PE1) получает маршрут VPN-IPv4 R1 и распространяет маршрут IPv4 R2 устройству CE, маршрут R2 не должен распространяться обратно с сайта CE маршрутизатору PE (скажем, PE2, где PE1 и PE2 могут быть одним или разными маршрутизаторами), если PE2 не отображает R2 на маршрут VPN-IPv4, который отличается (т. е. имеет иной идентификатор RD) от R1.

  3. Маршрутизаторы PE и CE могут быть партнерами OSPF. PE, являющийся OSPF-партнером маршрутизатора CE с точки зрения CE будет находиться в области 0. Если PE является партнером OSPF маршрутизаторов CE из разных VPN, PE должен поддерживать отдельные экземпляры OSPF для каждой VPN.

    Маршруты IPv4, которые PE получает от CE по протоколу OSPF, распространяются в BGP как маршруты VPN-IPv4. Атрибуты Extended Community служат для передачи вместе с маршрутом всех информации, требуемой для распространения маршрута другим CE в сети VPN в форме подходящих анонсов OSPF LSA37. Маршруты OSPF помечаются, чтобы принятые из магистрали MPLS/BGP маршруты не передавались обратно.

    Спецификация полного набора процедур использования OSPF между PE и CE приведена в [VPN-OSPF] и [OSPF-2547-DNBIT].

  4. Маршрутизаторы PE и CE могут быть партнерами BGP и CE может применять BGP (в частности, EBGP) для передачи PE набора адресных префиксов на сайте CE (это можно применять в транзитных и оконечных VPN).

    Этот метод обеспечивает многочисленные преимущества, перечисленные ниже.

    1. В отличие от IGP это не требует от PE использования множества экземпляров протокола маршрутизации для взаимодействия с множеством CE.

    2. Протокол BGP создан для решения таких задач — передачи маршрутной информации между системами с раздельным администрированием.

    3. Если сайт имеет «закулисные соединения BGP», т. е. маршрутизаторы с соединениями BGP с сайтами, не являющимися PE, эта процедура будет работать корректно при любых обстоятельствах, в отличие от других процедур, которые могут работать не во всех случаях.

    4. Использование BGP позволяет CE простым путем передавать атрибуты маршрутов маршрутизатору PE. Полная спецификация набора передаваемых атрибутов выходит за рамки документа. Однако некоторые примеры приводятся ниже.

      • CE может предложить конкретный атрибут RT для каждого маршрута из числа RT, которые PE уполномочен присоединять к маршрутам. PE будет тогда добавлять предложенный атрибут RT, а не полный набор атрибутов. Это дает администратору CE возможность динамического управления распространением маршрутов от CE.

      • Могут быть определены дополнительные типы атрибутов Extended Community для передачи между маршрутизаторами CE без изменения атрибутов устройствами PE. Это позволит администраторам CE реализовать дополнительные правила фильтрации маршрутов сверх тех, которые выполняются PE. Эти дополнительные правила не требуется согласовывать с SP.

С другой стороны, у администраторов CE может не оказаться опыта работы с BGP.

Если сайт не является транзитной VPN, ему не нужен уникальный номер автономной системы (ASN). Каждый CE, чей сайт не является транзитной VPN, может применять один и тот же номер ASN, который можно выбрать из приватных номеров ASN, поскольку он будет исключаться маршрутизатором PE. Маршрутные петли предотвращаются использованием атрибута Site of Origin (см. ниже).

Что делать в случаях, когда набор сайтов образует транзитную сеть VPN? Это обычно возникает лишь в тех случаях, когда VPN является сетью сервис-провайдера ISP38, который сам покупает магистральные услуги у другого SP (оператора для операторов). В этом случае лучшим вариантом организации VPN будет поддержка MPLS маршрутизаторами CE и применение метода, описанного в разделе 9.

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

До того, как PE сможет распространять маршруты VPN-IPv4, узнанные от сайта, он должен назначить атрибут RT (параграф 4.3.1) для маршрута и может назначить также атрибут Site of Origin.

При использовании атрибута Site of Origin он кодируется в форме Route Origin Extended Community [BGP-EXTCOMM]. Назначение этого атрибута заключается в однозначном указании набора маршрутов, полученного от конкретного сайта. Этот атрибут требуется в некоторых случаях для обеспечения гарантии того, что маршрут, полученный от конкретного сайта через определенное соединение PE — CE, не будет распространяться на этот же сайт через другое соединение PE — CE. Это полезно, в частности, при использовании протокола BGP между PE и CE с различными номерами ASN на разных сайтах.

8. Как CE узнают маршруты от PE

В этом разделе предполагается, что устройство CE является маршрутизатором.

Если PE помещает определенный маршрут в таблицу VRF и использует его для маршрутизации пакетов, полученных от конкретного CE, в общем случае PE может распространять этот маршрут CE (если это разрешают правила протокола, используемого между CE и PE). Например, если отдельный протокол PE — CE использует «расщепление горизонта» (split horizon), некоторые маршруты из VRF невозможно распространять устройству CE). Можно добавить одно ограничение на распространение маршрутов от PE к CE — если атрибут Site of Origin указывает определенный сайт, маршрут недопустимо распространять какому-либо CE на этом сайте.

Однако в большинстве случае для PE достаточно просто распространять устройству CE используемый по умолчанию маршрут (в некоторых случаях достаточно просто задать на CE использование по умолчанию маршрута к PE). Это обычно будет работать на любом сайте, которому не требуется распространять используемый по умолчанию маршрут другим сайтам (например, если один сайт в корпоративной VPN обеспечивает доступ в Internet для всей компании, этот сайт должен распространять принятый по умолчанию маршрут другим сайтам, но не может распространять его себе).

Какая бы процедура ни использовалась для распространения маршрутов из CE в PE, она же будет применяться для распространения маршрутов из PE в CE.

9. Операторы для операторов

В некоторых случаях VPN может быть сетью ISP с его партнерскими связями (peering) и политикой маршрутизации, а иногда VPN может быть сетью SP, предоставляющего услуги VPN своим абонентам. Такие сети VPN также могут использовать магистральные услуги других SP (оператора для операторов) на основе методов, описанных в этом документе. Однако в таких случаях требуется поддержка MPLS маршрутизаторами CE. Требования приведены ниже.

  • Маршрутизаторам CE следует распространять в PE только внутренние маршруты VPN. Это позволит VPN работать в режиме оконечной VPN.

  • Маршрутизаторам CE следует поддерживать MPLS в части возможности принимать метки от маршрутизаторов PE и передавать тем пакеты с метками. Эти маршрутизаторы не распространяют своих меток.

  • PE следует распространять маршрутизаторам CE метки для маршрутов, которые они распространяют CE.

    PE недопустимо распространять одну метку двум разным CE, если не выполняется одно из условий:

    • два CE связаны с одним набором таблиц VRF;

    • PE поддерживает разные отображения входящих меток [MPLS-ARCH] для каждого CE.

    Кроме того при получении PE пакета с меткой от CE он должен убедиться, что эта метка распространялась данному CE.

  • Маршрутизаторам разных сайтов следует организовать между собой соединения BGP для обмена внешними маршрутами (т. е. маршрутами, ведущими за пределы VPN).

  • Все внешние маршруты должны быть известны устройствам CE.

Когда маршрутизатор CE выполняет поиск по адресу получателя, он будет находить внутренний адрес, который обычно указывает BGP next hop для пакета. CE соответствующим образом помечает пакет и передает его маршрутизатору PE, который вместо поиска IP-адреса получателя в таблице VRF использует верхнюю метку MPLS для выбора BGP next hop. В результате, если до BGP next hop более одного интервала пересылки (hop), верхняя метка стека будет заменяться двумя метками — для туннеля и маршрута VPN. Если до BGP next hop лишь один интервал, верхняя метка может быть просто заменена меткой маршрута VPN. Если входной PE является одновременно выходным PE, верхняя метка будет просто выталкиваться из стека. При передаче пакета от выходного PE маршрутизатору CE, пакет будет иметь на одну метку MPLS меньше, чем было получено на входном PE.

В приведенной выше процедуре лишь маршрутизаторам CE в VPN требуется поддержка MPLS. С другой стороны, если все маршрутизаторы определенного сайта VPN поддерживают MPLS, от CE не требуется больше знать все внешние маршруты. Достаточно, чтобы внешние маршруты были известны маршрутизаторам, отвечающим за добавление меток в стек пакетов без меток и наличие пути с коммутацией по меткам от этих маршрутизаторов к их BGP-партнерам на других сайтах. В этом случае для каждого внутреннего маршрута, который CE распространяет маршрутизатору PE, должна добавляться метка.

10. Магистрали с множеством AS

Что будет, если два сайта VPN подключены к разным автономным системам (например, через разных SP)? Маршрутизаторы PE, связанные с данной VPN с этом случае не смогут организовать соединения IBGP между собой или с общим рефлектором маршрутов. Здесь потребуется организация соединений EBGP для распространения адресов VPN-IPv4.

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

  1. Соединения между VRF на граничных маршрутизаторах AS.

    В этом случае маршрутизатор PE одной AS соединяется напрямую с PE другой AS. Соединения между PE организуются через множество субинтерфейсов — по меньшей мере один интерфейс на каждую сеть VPN, для которой требуется работа через разные AS. Каждый маршрутизатор PE будет рассматривать другой PE как маршрутизатор CE. Т. е. маршрутизаторы PE связывают каждый субинтерфейс с VRF и используют EBGP для распространения адресов IPv4 без меток другому PE.

    Эта процедура не требует поддержки MPLS на граниче между AS. Однако она не обеспечивает достаточных возможностей расширения по сравнению с другими вариантами.

  2. EBGP служит для распространения маршрутов VPN-IPv4 с метками из одной AS в соседнюю.

    В этом варианте маршрутизаторы PE применяют IBGP для распространения маршрутов VPN-IPv4 граничному маршрутизатору ASBR39 или рефлектору маршрутов, для которого ASBR является клиентом. ASBR затем использует EBGP для распространения маршрутов VPN-IPv4 с метками маршрутизатору ASBR в другой AS, который в свою очередь распространяет из маршрутизаторам PE в своей AS и возможно другим ASBR и т. д.

    При использовании такой процедуры маршруты VPN-IPv4 следует воспринимать лишь на соединениях EBGP в приватных точках партнерства (peering point) как часть доверенных отношений между SP. Маршруты VPN-IPv4 не следует воспринимать из публичной сети Internet (и распространять туда) или от недоверенных партнеров BGP. Маршрутизатору ASBR не следует воспринимать помеченные пакеты от партнера EBGP, если он не распространял этому партнеру верхнюю метку из пакета.

    При наличии множества VPN с подключениями к разным AS не требуется наличие между автономными системами одного ASBR, которому известны маршруты для всех VPN между этими двумя AS, и может использоваться множество ASBR, каждый из которых поддерживает маршруты для определенного подмножества VPN.

    Эта процедура требует наличия пути с коммутацией по меткам от входного PE для пакета до его выходного PE. Поэтому нужны соответствующие отношения доверия между AS на пути пакетов. Также между SP должно иметься соглашения о выборе граничных маршрутизаторов для получения маршрутов с разными атрибутами RT.

  3. Распространение EBGP для помеченных маршрутов VPN-IPv4 между AS через множество этапов пересылки с распространением EBGP для помеченных маршрутов IPv4 из обной AS в соседнюю.

    В этом варианте маршруты VPN-IPv4 не поддерживаются и не распространяются маршрутизаторами ASBR, которые однако должны поддерживать помеченные маршруты IPv4 с префиксом /32 для маршрутизаторов PE внутри AS. Для распространения маршрутов в другие AS применяется EBGP. маршрутизаторы ASBR в транзитных AS будут также передавать по EBGP помеченные маршруты /32. Это обеспечивает создание пути с коммутацией по меткам от входного маршрутизатора PE к выходному PE. Маршрутизаторы PE в разных AS могут организовывать между собой соединения EBGP с множеством этапов пересылки и обмениваться черех них маршрутами VPN-IPv4.

    Если маршруты /32 для устройств PE известны маршрутизаторам P в каждой AS, все работает хорошо. Если маршруты /32 для PE не известны маршрутизаторам P (кроме ASBR), эта процедура требует от входного PE помещать в пакет стек из 3 меток. Нижняя метка назначается выходным PE, соответствующим адреса получателя пакета в определенной таблице VRF. Среднюю метку назначает маршрутизатор ASBR, соответствующий маршруту /32 к входному PE. Рерхняя метка назначается узлом IGP Next Hop для PE, соответствующим маршруту /32 к ASBR.

    Для улучшения расширяемости можно использовать многоэтапные соединения EBGP лишь между рефлекторами маршрутов в разных AS (однако при распространении рефлекторами маршрутов через такое соединение они не меняют атрибут BGP next hop). Тогда маршрутизаторы PE будут иметь лишь соединения IBGP с рефлекторами маршрутов в своей AS.

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

11. Доступ в Internet из VPN

Многим сайтам VPN нужен доступ в публичную сеть Internet, а также к другим сайтам VPN. Ниже описано несколько вариантов решения этих задач.

  1. В некоторых VPN один или несколько сайтов могут получать доступ в Internet с помощью «шлюза Internet» (возможно, межсетевого экрана), подключенного к интерфейсу в сеть ISP без таблицы VRF. Это может быть тот же провайдер, который обеспечивает услуги VPN, или другой ISP. Трафик на шлюз и от него будет маршрутизироваться с использованием принятой по умолчанию таблицы пересылки PE.

    В этом случае сайты с доступом в Internet могут распространять принятый по умолчанию маршрут своим PE, которые затем распространят его другим PE на других сайтах VPN. Это обеспечит доступ в Internet на всех сайтах VPN.

    Для корректной обработки трафика из Internet провайдер ISP должен распространить в сеть Internet маршруты, ведущие к адресам VPN. Это никак не связано с процедурами распространения маршрутов, описанными в этом документе. Внутренняя структура VPN в общем случае не видна из Internet и эти маршруты будут просто вести к интерфейсу без VRF, подключенному к шлюзу Internet в сети VPN.

    В этой модели не происходит обмена маршрутами между принятой по умолчанию таблицей пересылки PE и какими-либо из его VRF. Процедуры распространения маршрутов VPN и Internet полностью независимы.

    Отметим, что хотя некоторые сайты VPN используют интерфейс VRF для обмена данными с Internet, в конечном итоге все пакеты в сеть Internet и из нее проходят через интерфейс без VRF перед выходом из VPN или входом в нее, поэтому этот вариант называется доступом в Internet без VRF (non-VRF Internet access).

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

  2. Некоторые VPN могут получать доступ в Internet через интерфейс VRF (VRF Internet access). Если пакет принят PE через интерфейс VRF и адрес получателя в нем не соответствует ни одному маршруту из VRF, этот пакет может быть сопоставлен с принятой по умолчанию таблицей пересылки PE. При обнаружении соответствия пакет можно переслать обычным путем через магистральную сеть в Internet, не применяя MPLS.

    Для трафика в обратном направлении (из Internet на интерфейс VRF), некоторые из маршрутов VRF должны экспортироваться в таблицу пересылки Internet. Нет нужды говорить о том, что это должны быть маршруты к уникальным в глобальном масштабе адресам.

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

  3. Предположим, что PE иметт возможность сохранять не связанные с VPN маршруты в таблице VRF. Если пакет имеет адрес получателя, соответствующий маршруту «не VPN», он будет передаваться естественным путем, а не через MPLS. Если VRF содержит принятый по умолчанию маршрут «не VPN», все пакеты для публичной сети Internet будут соответствовать ему и передаваться естественным путем по принятому по умолчанию маршруту на следующий интервал. Там будет выполняться поиск по адресу получателя в принятой по умолчанию таблице пересылке и может быть выбран более точный маршрут.

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

  4. Можно также получать доступ в Internet через интерфейс VRF путем включения в таблицу VRF маршрутов Internet. По сравнению с моделью 2 это избавляет от второй операции поиска, но требует репликации маршрутов Internet в каждую таблицу VRF.

    При использовании этого метода SP может захотеть использовать в качестве интерфейса в Internet интерфейс VRF и применять методы раздела 4 для распространения маршрутов Internet как маршрутов VPN-IPv4 в другие VRF.

Следует понимать, что по умолчанию не происходит обмена маршрутами между VRF и принятой по умолчанию таблицей пересылки. Такой обмен выполняется лишь по соглашению между абонентом и SP и только при соответствии правилам абонента.

12. VPN для управления

Эта спецификация не требует наличия адреса у субинтерфейса, соединяющего маршрутизаторы PE и CE. Если этот интерфейс имеет адрес, спецификация позволяет использовать адресное пространство VPN или SP.

Если маршрутизатор CE управляется сервис-провайдером, системе управления сетью SP будет нужен доступ к маршрутизатору CE. В этом случае субинтерфейсу между CE и PE следует назначать адрес из пространства SP и этот адрес должен быть уникальным в рамках провайдера. Системе управления сетью следует самостоятельно подключиться к маршрутизатору PE (точнее, присутствовать на сайте, подключенном к PE) через интерфейс VRF. Адрес системы управления будет экспортироваться во все таблицы VRF, связанные с интерфейсами к маршрутизаторам CE, которыми управляет SP. Адреса маршрутизаторов CE будут экспортироваться в VRF, связанные с системой сетевого управления, но не в остальные VRF.

Это разрешает взаимодействие между CE и системой сетевого управления но препятствует ненужному взаимодействию между маршрутизаторами CE.

Одним из способов организации нужного экспорта и импорта маршрутов является использование двух атрибутов RT, например T1 и T2. Если конкретный интерфейс VRF подключен к маршрутизатору CE, управляемому SP, для этой таблицы VRF настраиваются:

  • импорт маршрутов с атрибутом T1;

  • добавление атрибута T2 к адресам, настроенным на каждой стороне интерфейсов VRF.

Если конкретный интерфейс VRF подключен к системе управления SP, для таблицы VRF настраивается добавление атрибута T1 к адресу этой системы и импорт маршрутов с атрибутом T2.

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

13.1. Уровень данных

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

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

  • Передача на один из сайтов VPN пакетов извне VPN, не разрешенных политикой VPN.

Ниже перечислено несколько условий, при соблюдении которых защита уровня данных, обеспечиваемая этой архитектурой, виртуально идентична защите VPN в магистралях Frame Relay или ATM. Если находящиеся под управлением SP устройства настроены корректно, данные не смогут попадать в сеть VPN или уходить их нее без должных полномочий.

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

  2. Помеченные маршруты VPN-IPv4 не воспринимаются из недоверенных или ненадежных партненов по маршрутизации.

  3. Не было успешных атак на уровень управления.

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

  • Верхняя метка в пакете имеет значение, которое принимающая система распространила данному соседу.

  • Верхняя метка в пакете имеет значение, которое принимающая система распространила системам, находящимся за этим соседом (т. е. известно, что путь от системы, которой распространена метка, до принимающей системы проходит через этого соседа).

Условие 2 наиболее интересно для случая организации VPN с участием нескольких провайдеров (раздел 10). Для межпровайдерских VPN, создаваемых по схеме b) из раздела 10, условие 2 легко проверить (безопасность для схемы c) из раздела 10 требует дополнительного изучения).

Важно подчеркнуть, что использование MPLS значительно упрощает обеспечение безопасности уровня данных по сравнению с использованием той или иной формы туннелей IP вместо внешней метки MPLS. Очень просто сделать так, чтобы граничные маршрутизаторы отказывались воспринимать помеченные пакеты, если для них не выполняется условие 1. Существенно сложнее настроить маршрутизатор так, чтобы он отвергал туннелированные пакеты IP, в которых получателем указан данный маршрутизатор PE, — это можно сделать, но за счет более сложного управления и снижения производительности.

Туннелирование MPLS-in-IP и MPLS-in-GRE описано в [MPLS-in-IP-GRE]. Если нужно применять такие туннели для передачи пакетов VPN, следует разобраться с вопросами безопасности, упомянутыми в разделе 8 указанного документа. Любая реализация BGP/MPLS IP VPN, разрешающая туннелировать пакеты VPN в соответствии с указанным документом, должна поддерживать IPsec. Если туннель не защищен с помощью IPsec, фильтрация по адресам IP на граничных маршрутизаторах, описанная в параграфе 8.2 упомянутого документа, остается единственным способом гарантировать, что пакеты, выходящие из туннеля на конкретном выходном PE, действительно были помещены в туннель разрешенным узлом в начале туннеля (т. е. пакет не содержит обманный адрес отправителя). Поскольку граничные маршрутизаторы зачастую фильтруют лишь по адресам отправителей, фильтрация пакетов может быть неэффективной, пока выходной маршрутизатор PE не может проверить IP-адрес отправителя любого туннелированного пакета и сравнить его со списком адресов IP, которые разрешены в начальной чточке туннеля. Все реализации, разрешающие туннели MPLS-in-IP и/или MPLS-in-GRE без IPsec должны позволять выходному PE такую проверку IP-адресов отправителей для всех принимаемых из туннеля пакетов.

При подключении множества CE к маршрутизатору PE через интерфейс ЛВС для обеспечения безопасности должно выполняться одно из приведенных ниже условий.

  1. Все маршрутизаторы CE в ЛВС должны относиться к одной сети VPN.

  2. Доверенный и защищенный коммутатор ЛВС делит сеть на несколько VLAN, каждая из которых включает лишь системы одной сети VPN. В этом случае коммутатор будет добавлять подходящий тег VLAN ко всем пакетам, пересылаемым маршрутизатору PE.

Эта архитектура не обеспечивает криптографической защиты конфиденциальности, так же как в Frame Relay или ATM VPN. Эти варианты архитектуры совместимы с использованием криптографии на базе CE-CE, если это нужно.

Использование криптографии между устройствами PE требует дополнительного исследования.

13.2. Уровень управления

Безопасность уровня данных, рассмотренная выше, зависит от защиты уровня управления. Для обеспечения безопасности не следует разрешать соединения BGP или LDP с недоверенными партнерами. Следует применять опцию проверки подлинности TCP/IP MD5 [TCP-MD5] с обоими протоколами. Протокол маршрутизации в сети SP также следует защищать аналогичым способом.

13.3. Защита устройств P и PE

При нарушении физической защиты этих устройств уровень данных также подвергается рискам.

Следует применять обычные меры защиты от использования трафика IP из публичной сети Internet для изменения конфигурации этих устройств или организации против них атак на службы (Denial of Service).

14. Качество обслуживания

Хотя качество обслуживания не рассматривается в этом документе, вопросы QoS40 являются важной частью сервиса VPN. В сетях MPLS/BGP VPN имеющиеся возможности L3 QoS могут применяться к помеченным пакетам за счет использования экспериментальных битов в промежуточном заголовке [MPLS-ENCAPS] или, при работе через магистрали ATM, за счет использования ATM QoS. Организация трафика, описанная в [MPLS-RSVP], также применима для сетей MPLS/BGP VPN. Организацию трафика можно даже использовать для организации путей с коммутацией по меткам и заданными параметрами QoS между парой конкретных сайтов, если это нужно. При организации MPLS/BGP VPN через несколько SP может быть полезна архитектура, описанная в [PASTE]. SP может применять возможности интегрированного (intserv41) или дифференцированного (diffserv42) для конкретной сети VPN по своему усмотрению.

15. Расширяемость

В этом документе были рассмотрены вопросы расширяемости и в этом разделе приведено краткое резюме по характеристикам расширяемости этой модели.

Магистральная сеть SP состоит из (a) маршрутизаторов PE, (b) рефлекторов маршрутов BGP, © маршрутизаторов P (не PE и не рефлекторы маршрутов), а в случае межпровайдерских VPN включает (d) граничные маршрутизаторы ASBR.

Маршрутизаторы P не поддерживают маршрутов VPN и для правильной пересылки трафика VPN им достаточно поддерживать маршруты к PE и ASBR. Использование двух уровней меток обеспечивает возможность сохранения маршрутов VPN при передаче трафика через маршрутизаторы P.

Маршрутизаторы PE поддерживают маршруты VPN лишь для сетей VPN, к которым они подключены напрямую.

Рефлекторы маршрутов могут быть разделены между VPN так, что каждая часть обслуживает лишь подмножество VPN, обслуживаемых SP. Таким образом, ни одному рефлектору не нужно знать маршрутов для всех VPN.

Для межпровайдерских VPN маршрутизаторы ASBR, поддерживающие и распространяющие маршруты VPN-IPv4, могут быть разделены между VPN как рефлекторы и в результате не одному ASBR не потребуется знать маршруты во все межпровайдерские VPN. При использовании multi-hop EBGP маршрутизаторам ASBR не требуется поддерживать и распространять маршруты VPN-IPv4.

В результате в сети SP не требуется наличия одного узла, знающего все маршруты для всех VPN. Поэтому число поддерживаемых в сети VPN не ограничивается возможностями отдельных компонентов.

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

Агентство IANA43 организовало новый реестр Route Distinguisher Type Field (параграф 4.2). Это поле является двухбайтовым. Типы 0 — 2 определены в этом документе. Дополнительные значения Route Distinguisher Type Field со старшим битом 0 выделяются IANA в порядке очередности запросов (First Come, First Served) в соответствии с [IANA]. Значения со старшим битом 1 выделяются IANA по согласованию с IETF (IETF consensus) в соответствии с [IANA].

Этот документ (параграф 4.3.4) задает использование BGP Address Family Identifier (AFI) со значением 1 вместе с BGP Subsequent Address Family Identifier (SAFI) со значением 128 для представления семейства адресов VPN-IPv4 с метками, определенного в этом документе.

Использование AFI = 1 для адресов IP в настоящее время задано реестом IANA Address Family Identifier, поэтому от IANA не требуется дополнительных действий.

Значение SAFI = 128 изначально было выделено для частных применений (Private Use) в реестре IANA Subsequent Address Family Identifier. Агентство IANA изменило для SAFI = 128 запись «private use» на «MPLS-labeled VPN address».

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

Полный список участников работы представлен в разделе 18.

Важный вклад в работу внесли также Ravi Chandra, Dan Tappan и Bob Thomas.

Спасибо Shantam Biswas за его рецензию и вклад в работу.

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

Tony Bogovic

Telcordia Technologies

445 South Street, Room 1A264B

Morristown, NJ 07960

EMail: tjb@research.telcordia.com

Stephen John Brannon

Swisscom AG

Postfach 1570

CH-8301

Glattzentrum (Zuerich), Switzerland

EMail: stephen.brannon@swisscom.com

Marco Carugi

Nortel Networks S.A.

Parc d’activites de Magny-Les Jeunes Bois CHATEAUFORT

78928 YVELINES Cedex 9 — FRANCE

EMail: marco.carugi@nortelnetworks.com

Christopher J. Chase

AT&T

200 Laurel Ave

Middletown, NJ 07748

USA

EMail: chase@att.com

Ting Wo Chung

Bell Nexxia

181 Bay Street

Suite 350

Toronto, Ontario

M5J2T3

EMail: ting_wo.chung@bellnexxia.com

Eric Dean

Jeremy De Clercq

Alcatel Network Strategy Group

Francis Wellesplein 1

2018 Antwerp, Belgium

EMail: jeremy.de_clercq@alcatel.be

Luyuan Fang

AT&T

IP Backbone Architecture

200 Laurel Ave.

Middletown, NJ 07748

EMail: luyuanfang@att.com

Paul Hitchen

BT

BT Adastral Park

Martlesham Heath,

Ipswich IP5 3RE

UK

EMail: paul.hitchen@bt.com

Manoj Leelanivas

Juniper Networks, Inc.

385 Ravendale Drive

Mountain View, CA 94043 USA

EMail: manoj@juniper.net

Dave Marshall

Worldcom

901 International Parkway

Richardson, Texas 75081

EMail: dave.marshall@wcom.com

Luca Martini

Cisco Systems, Inc.

9155 East Nichols Avenue, Suite 400

Englewood, CO, 80112

EMail: lmartini@cisco.com

Monique Jeanne Morrow

Cisco Systems, Inc.

Glatt-com, 2nd floor

CH-8301

Glattzentrum, Switzerland

EMail: mmorrow@cisco.com

Ravichander Vaidyanathan

Telcordia Technologies

445 South Street, Room 1C258B

Morristown, NJ 07960

EMail: vravi@research.telcordia.com

Adrian Smith

BT

BT Adastral Park

Martlesham Heath,

Ipswich IP5 3RE

UK

EMail: adrian.ca.smith@bt.com

Vijay Srinivasan

1200 Bridge Parkway

Redwood City, CA 94065

EMail: vsriniva@cosinecom.com

Alain Vedrenne

Equant

Heraklion, 1041 route des Dolines, BP347

06906 Sophia Antipolis, Cedex, France

EMail: Alain.Vedrenne@equant.com

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

[BGP] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, «Multiprotocol Extensions for BGP-4», RFC 285844, June 2000.

[BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, «BGP Extended Communities Attribute», RFC 4360, February 2006.

[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, January 2001.

[MPLS-BGP] Rekhter, Y. and E. Rosen, «Carrying Label Information in BGP-4», RFC 310745, May 2001.

[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

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

[BGP-AS4] Vohra, Q. and E. Chen, «BGP Support for Four-Octet AS Number Space», Work in Progress46, March 2004.

[BGP-ORF] Chen, E. and Y. Rekhter, «Cooperative Route Filtering Capability for BGP-4», Work in Progress47, March 2004.

[BGP-RFSH] Chen, E., «Route Refresh Capability for BGP-4», RFC 2918, September 2000.

[BGP-RR] Bates, T., Chandra, R., and E. Chen, «BGP Route Reflection — An Alternative to Full Mesh IBGP», RFC 279648, April 2000.

[IANA] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 243449, October 1998.

[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, «MPLS using LDP and ATM VC Switching», RFC 3035, January 2001.

[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T’Joens, Y., and C. Sargor, «Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs», Work in Progress, March 2004.

[MPLS-FR] Conta, A., Doolan, P., and A. Malis, «Use of Label Switching on Frame Relay Networks Specification», RFC 3034, January 2001.

[MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen, «Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)», RFC 4023, March 2005.

[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, «LDP Specification», RFC 303650, January 2001.

[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, December 2001.

[OSPFv2] Moy, J., «OSPF Version 2», STD 54, RFC 2328, April 1998.

[PASTE] Li, T. and Y. Rekhter, «A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)», RFC 2430, October 1998.

[RIP] Malkin, G., «RIP Version 2», STD 56, RFC 2453, November 1998.

[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault, «Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs», Work in Progress51, March 2004.

[TCP-MD5] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, «Multicast in MPLS/BGP VPNs», Work in Progress52, May 2004.

[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, «OSPF as the PE/CE Protocol in BGP/MPLS VPNs», Work in Progress53, February 2004.


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

Eric C. Rosen

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

EMail: erosen@cisco.com

Yakov Rekhter

Juniper Networks

1194 N. Mathilda Avenue

Sunnyvale, CA 94089

EMail: yakov@juniper.net


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

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

nmalykh@protocols.ru

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

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 ietf-ipr@ietf.org.

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

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

1Service Provider.

2Virtual Private Network.

3Customer edge.

4Provider edge.

5Border Gateway Protocol — протокол граничного шлюза.

6Multiprotocol Label Switching — многопротокольная коммутация по меткам.

7Generic Routing Encapsulation — базовая инкапсуляция маршрутных данных.

8Internet Service Provider.

9Asynchronous Transfer Mode — асинхронный режим передачи.

10High Level Data Link Control — управление каналом данных на высоком уровне.

11Point-to-Point Protocol — протокол «точка-точка».

12Virtual Circuit.

13Virtual Local Area Network.

14Layer 2 Tunneling Protocol — протокол туннелирования L2.

15Customer Edge.

16Provider Edge.

17Open Shortest Path First — сначала кратчайший путь.

18VPN Routing and Forwarding table — таблица маршрутизации и пересылки VPN.

19Data Link Connection Identifier — идентификатор соединения на канальном уровне.

20Route Distinguisher — отличие (обозначение) маршрута.

21Autonomous System number.

22Route Target — цель маршрута.

23Network Layer Reachability Information — информация о доступности на сетевом уровне.

24Address Resolution Protocol — протокол преобразования адресов.

25Quality of Service — качество обслуживания.

26Label Distribution Protocol — протокол распространения меток.

27Label Controlled ATM — ATM с управлениям по меткам.

28Label Controlled Frame Relay — Frame Relay с управлениям по меткам.

29Route Reflector.

30Outbound Route Filter.

31Добавление новой сети VPN на PE реально означает добавление нового импорта RT в одну из его таблиц VRF или добавление новой VRF с импортом RT, которого нет в других VRF этого PE.

32Address Family Identifier — идентификатор семейства адресов.

33Subsequent Address Family Identifier — идентификатор последующего семейства адресов.

34Концентратор и лучи.

35Autonomous System — автономная система.

36Routing Information Protocol — протокол маршрутной информации.

37Link State Advertisement — анонс состояния канала.

38Internet Service Provider — поставщик услуг доступа в Internet.

39Autonomous System Border Router — граничный маршрутизатор автономной системы.

40Quality of Service — качество обслуживания.

41Integrated Services — интегрированное обслуживание.

42Differentiated Services — дифференцированное обслуживание.

43Internet Assigned Numbers Authority.

44Заменен RFC 4760. Прим. перев.

45Заменен RFC 8277. Прим. перев.

46Работа опубликована в RFC 4893, который заменен RFC 6793. Прим. перев.

47Работа опубликована в RFC 5291. Прим. перев.

48Заменен RFC 4456. Прим. перев.

49Заменен RFC 5226. Прим. перев.

50Заменен RFC 5036. Прим. перев.

51Работа опубликована в RFC 4576. Прим. перев.

52Работа опубликована в RFC 6513. Прим. перев.

53Работа опубликована в RFC 4577. Прим. перев.




RFC 4384 BGP Communities for Data Collection

Network Working Group                                       D. Meyer
Request for Comments: 4384                             February 2006
BCP: 114
Category:  Best Current Practice

 

Группы BGP для сбора данных

BGP Communities for Data Collection

PDF

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

Этот документ описывает практический опыт (Internet Best Current Practices) для сообщества Internet и является приглашением к дискуссии в целях развития и совершенствования. Документ может распространяться свободно.

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

Copyright (C) The Internet Society (2006).

Тезисы

Группы BGP1 (RFC 1997) используются сервис-провайдерами для разных целей, включая метки маршрутов в соответствии с заказчиком, партнером или географией исходной точки. Такие метки обычно служат для контроля за областью распространения маршрутов в сети провайдера, а также среди его партнеров и заказчиков. Из результатов крупномасштабного сбора данных BGP (и связанных с этим исследований) становится ясно, что передаваемая в таких группах весьма важна для более глубокого понимания глобальной системы маршрутизации. В этом документе определяются стандартные (исходящие – outbound) группы и их представление для экспорта в системы сбора маршрутной информации BGP2.

Оглавление

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

1. Введение

Группы BGP [RFC1997] используются сервис-провайдерами для разных целей, включая метки маршрутов в соответствии с заказчиком, партнером или географией исходной точки. Такие метки обычно служат для контроля за областью распространения маршрутов в сети провайдера, а также среди его партнеров и заказчиков. Группы также используются для широкого спектра других приложений, таких, как предоставление потребителям возможности установки атрибутов типа LOCAL_PREF [RFC1771] путем передачи соответствующих групп своему провайдеру. К числу приложений относится также сигнализация различных типов VPN3 (например, VPLS4 [VPLS]), и передача информации о ширине полосы для систем управления трафиком [RFC4360].

Из результатов крупномасштабного сбора данных BGP [RV] [RIS] (и связанных с этим исследований) становится ясно, что географическая и топологическая информация, а также отношение провайдера к исходной точке маршрута (например, транзитный узел, партнер или потребитель), содержащиеся в таких группах, весьма важны для более глубокого понимания глобальной системы маршрутизации. В этом документе определяются стандартные группы для экспорта с системы сбора маршрутной информации BGP. Эти группы представляют существенную часть информации, передаваемой сервис-провайдерами, и данные могут быть полезными для решения внутренних задач сервис-провайдеров. Однако такое использование данных выходит за пределы настоящего документа. Тем, кто вовлечен в анализ данных BGP, рекомендуется проверить какие из их источников данных реализуют эту схему (поскольку существует большое количество данных, а также множество унаследованных партнерских отношений).

Оставшаяся часть документа организована следующим образом – глава 2 содержит определения терминов, которые применяются как семантика групп, используемых для сбора данных BGP, а глава 3 определяет соответствующее кодирование групп RFC 1997 [RFC1997]. Наконец, в главе 4 определяется кодирование для использования с расширенными группами [RFC4360].

2. Определения

В этой главе мы определим используемые термины и категории маршрутов, которые могут помечаться с помощью групп. Такие метки часто называют «окрашиванием» и мы будем говорить о “цветах” маршрутов, задаваемых принадлежностью к группам. Определенные здесь категории напоминают описанные в работах [WANG] и [HUSTON].

2.1. Партнеры и партнерство

Рассмотрим двух сервис-провайдеров, A и B. Эти провайдеры считаются партнерами, если (i) A и B обмениваются маршрутами по протоколу BGP и (ii) обмен трафиком между A и B происходит на бесплатной основе. Такое соглашение обычно называют партнерством5. Партнеры обычно обмениваются между собой только маршрутами к своим клиентам (см. следующий параграф) и, следовательно, обмениваются между собой только клиентским трафиком. Более детальное обсуждение бизнес-моделей, близких к партнерству, можно найти в работе [HUSTON].

2.2. Маршруты потребителей

Маршруты потребителей (Customer route) – это те маршруты, которые получены от заказчиков через протокол BGP и распространяются партнерам и другим потребителям. Отметим, что потребителем (заказчиком) может быть организация или другой сервис-провайдер. Такие маршруты иногда называют клиентскими (client route) [HUSTON].

2.3. Маршруты партнеров

Маршруты партнеров (Peer route) – это те маршруты, которые были получены от партнеров по протоколу BGP и не распространяются другим партнерам. Однако такие маршруты распространяются потребителям данного провайдера.

2.4. Внутренние маршруты

Внутренние маршруты (Internal route) – это маршруты, исходящие от данного сервис-провайдера и передаваемые партнерам и заказчикам. Эти маршруты зачастую выбираются из выделенного провайдеру адресного пространства.

2.5. Внутренние более специфичные маршруты

Внутренние более специфичные маршруты (Internal more specific route) – это маршруты, которые часто используются в целях балансировки нагрузки и снижения числа маршрутов IGP6. Они могут также соответствовать службам, которые недоступны за пределами сети данного провайдера. Такие маршруты не экспортируются никаким внешним партнерам.

2.6. Маршруты специального назначения

Маршруты специального назначения (Special purpose route) – это те маршруты, которые не могут быть отнесены ни к одному из описанных здесь классов. В тех случаях, когда такие маршруты требуется как-то выделить, сервис-провайдер может окрасить их с использованием уникального цвета. Примерами маршрутов специального назначения являются anycast-маршруты7 и маршруты для перекрывающихся сетей (overlay network).

2.7. Восходящие маршруты

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

2.8. Национальные маршруты

Набор маршрутов, начинающихся и/или полученных из определенной страны.

2.9. Региональные маршруты

Некоторые глобальные магистрали реализуют региональную политику, основанную на географии развернутой ими сети, а также на их стратегии и требованиях бизнеса. Сервис-провайдеры часто имеют в одном регионе бесплатные (settlement-free) соединения с AS, которые в другом регионе являются потребителями. Это вынуждает использовать региональную политику, включающую атрибуты групп, устанавливаемые сетью, для того, чтобы можно было легко различать маршруты разных регионов. Например, сервис-провайдер может трактовать набор маршрутов, полученных от другого сервис-провайдера в Европе, совсем не так, как тот же набор маршрутов, полученный в северной Америке, поскольку повсеместно может устанавливаться платный транзит для одних регионов и бесплатное партнерство – для других.

3. Кодирование и значения групп RFC 1997

В этой главе приводятся значения групп (community) RFC 1997 [RFC1997] для описанных выше категорий. Группы RFC 1997 кодируются как BGP Type Code 8 и трактуются как 32битовые значений из диапазона 0x0000000 — 0xFFFFFFF. Значения от 0x0000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF зарезервированы.

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            <AS>               |         <Value>               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<AS> представляет собой 16-битовый номер автономной системы. Например, значение 0x2A7C029A будет представлять AS 10876 и значение 666.

4. Значения Community для сбора данных BGP

В этой главе мы определим для описанных выше категорий маршрутов кодирование групп RFC 1997, которые используются для сбора данных BGP. Предполагается, что используемые сервис-провайдерами внутренние значения будут приведены в соответствие с этими стандартными значениями для вывода в системы сбора маршрутных данных (route collector).

Этот документ следует общепринятой на сегодняшний день практике использования базового формата <AS>:<Value>. Значения для разных категорий маршрутов приведены в таблице.

Категория Значение
Резерв <AS>:0000000000000000
Маршруты потребителей <AS>:0000000000000001
Маршруты партнеров <AS>:0000000000000010
Внутренние маршруты <AS>:0000000000000011
Внутренние более специфичные маршруты <AS>:0000000000000100
Маршруты специального назначения <AS>:0000000000000101
Восходящие маршруты <AS>:0000000000000110
Резерв <AS>:0000100000000000 — <AS>:0000011111111111
Национальные и региональные маршруты
Кодируются как
<AS>:1111111111111111
<AS>:<R><X><CC>
Зарезервированные национальные и региональные маршруты <AS>:0100000000000000 — <AS>:1111111111111111

где

<AS> — 16-битовый номер AS;

<R> — 5-битовый идентификатор региона;

<X> — 1-битовая индикация спутниковых каналов (X = 1 для спутниковых каналов, 0 – для прочих);

<CC> — 10-битовый код страны ISO-3166-2 [ISO3166]

Идентификатор <R> может принимать значения:

Африка (AF) 00001

Океания (OC) 00010

Азия (AS) 00011

Антарктика (AQ) 00100

Европа (EU) 00101

Латинская Америка и Карибские острова (LAC) 00110

Северная Америка (NA) 00111

Резерв 01000 — 11111

Формат значения для национального или регионального маршрута показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            <AS>               |   <R>   |X|        <CC>       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Например, кодирование национального маршрута через наземный канал в AS 10876 с островов Фиджи (Fiji) будет иметь вид:

<AS> = 10876 = 0x2A7C

<R> = 00010

<X> = 0

<CC> = код страны для островов Фиджи 242 = 0011110010

В этом случае младшие 16 битов будут иметь значение 0001000011110010 = 0x10F2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           0x2A7C              |           0x10F2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Отметим, что конфигурационный язык может позволять спецификацию этой группы в форме 10876:4338 (4338 – десятичное представление 0x10F2).

Отметим, что эти категории не являются взаимоисключающими и допускается указание множества групп в тех случаях, где это подходит.

4.1. Расширенные группы

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

Атрибут Extended Communities является необязательным переходным атрибутом BGP с кодом типа (Type Code) 16. Атрибут содержит в себе набор расширенных групп в показанном ниже формате.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type high    |  Type low(*)  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Для сбора данных BGP мы кодируем описанные в параграфе 4 группы с использованием типа two-octet AS specific extended community8, который имеет следующий формат:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x00     |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Administrator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Группа two-octet AS specific extended community attribute содержит 2-октетный номер автономной системы провайдера (присвоенный ему региональным регистратором или RIR9) в поле Global Administrator, а поле Local Administrator может кодировать любую информацию.

В этом документе выделяется значение субтипа (Sub-Type) 0x0008 для сбора данных BGP и задается значение поля <Value> (в соответствии с параграфом 3.1) для двух младших октетов поля Local Administrator. Два старших октета поля Local Administrator зарезервированы – они устанавливаются в 0x00 при передаче и игнорируются на принимающей стороне.

Например, кодирование расширенной группы 10876:4338, представляющей наземный маршрут в AS 10876 с островов Фиджи, будет иметь вид:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x00     |      0x0008   |           0x2A7C              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x00     |      0x00     |           0x10F2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. 4-октетные расширенные группы уровня AS

Группы four-octet AS specific extended community кодируются следующим образом:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x02     |    0x0008     |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |           0x10F2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В этом случае 4-октетное субполе Global Administrator содержит четырехоктетный номер AS, выделенный IANA.

5. Замечание по упаковке сообщений BGP UPDATE

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

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

Описанное в этом документе кодирование групп порождено интересным предложением от Akira Kato из WIDE. В частности, ему принадлежит идея использовать набор значений групп для выбора путей, которые будут (к счастью) повышать эффективность доступа к различным типам сервиса. Например, для сервиса DNS на основе RFC 3258 [RFC3258] маршрутизаторы BGP могут видеть множество путей к одному префиксу. Эти маршруты могут иметь общее происхождение, но разные пути через сеть, а некоторые могут различаться по странам и регионам (с той же самой исходной AS).

Joe Abley, Randy Bush, Sean Donelan, Xenofontas Dimitropoulos, Vijay Gill, John Heasley, Geoff Huston, Steve Huter, Michael Patton, Olivier Marce, Ryan McDowell, Rob Rockell, Rob Thomas, Pekka Savola, Patrick Verkaik и Alex Zinin внесли множество полезных комментариев в ранние варианты этого документа. Henk Uijterwaal предложил использовать коды стран ISO-3166-2.

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

Хотя этот документ не порождает дополнительных вопросов безопасности для протокола BGP, содержащаяся в группах информация, которая определена в данном документе, может в некоторых случаях раскрывать структуру сети, которая до этого не была видна за пределами сети провайдера. В связи с этим следует соблюдать предосторожности при экспорте таких групп в системы сбора маршрутной информации (route collector). Маршруты, экспортируемые в route collector, следует помечать атрибутом группы NO_EXPORT (0xFFFFFF01).

7.1. Общий размер атрибутов

Описанные в этом документе группы предназначены для использования на выходе в систему сбора маршрутной информации (route collector). Следовательно, оператор может заменить свои внутренние группы на заданные этим документом значения при экспорте маршрутов в route collector. Однако операторам следует быть уверенными в том, что их реализация BGP корректно будет вести себя в тех случаях, когда в результате добавления атрибутов размер PDU превысит 4096 октетов. Например, поскольку общепринятой практикой является использование групп для реализации политики (скажем, обеспечения потребителям возможности установки таких атрибутов, как LOCAL_PREF), поведение реализации в случаях переполнения пространства атрибутов может играть критическую роль. Некоторые реализации могут в таких случаях захватывать данные атрибута или вызывать неопределенные отказы. Такое поведение может привести к установке неожиданных наборов атрибутов community и, следовательно, оказать нежелательное влияние на политику.

8. Согласование с IANA

Данный документ определяет новый субтип (Sub-Type) для типа AS specific extended community в категории расширенных переходных значений, распределяемой на основе правила First Come First Served10. Агентство IANA выделило для Sub-Type значение 0x0008, как определено в парашрафе 4.1.

В дополнение к сказанному агентство IANA создало два реестра для BGP Data Collection Communities – один для стандартных11, а второй для расширенных групп. Оба эти реестра в своем исходном состоянии включают значения, описанные в параграфе 4. Для выделения новых значений в этих реестрах (в частности, для <Value> или <R> в таблице значений для категорий маршрутов, описанных в параграфе 4) используется процедура IETF Consensus, как описано в [RFC2434]. Обычно это делается через рабочую группу GROW12.

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

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

[ISO3166] «ISO 3166 Maintenance agency (ISO 3166/MA)», http://www.iso.org/iso/en/prods-services/iso3166ma/index.html, 2004.

[RFC1771] Rekhter, Y. and T. Li (Editors), «A Border Gateway Protocol (BGP-4)», RFC 1771, March 1995.

[RFC1997] Chandra, R. and P. Traina, «BGP Communities Attribute», RFC 1997, August 1996.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, «BGP Extended Communities Attribute», RFC 4360, January 2006.

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

[HUSTON] Huston, G., «Interconnection, Peering, and Settlements», http://www.isoc.org/inet99/proceedings/1e/1e_1.htm

[RFC2434] Narten, T., and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC3258] Hardie, T., «Distributing Authoritative Name Servers via Shared Unicast Addresses», RFC 3258, April 2002.

[RIS] «The RIPE Routing Information Service», http://www.ripe.net/ris, 2004.

[RV] Meyer, D., «The Routeviews Project», http://www.routeviews.org, 2002.

[VPLS] Kompella, K., et al., «Virtual Private LAN Service», Work in Progress, April 2005.

[WANG] Wang, F. and L. Gao, «Inferring and Characterizing Internet Routing Policies»15, ACM SIGCOMM Internet Measurement Conference 2003.

Адрес автора

David Meyer

EMail: dmm@1-4-5.net


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

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

nmalykh@protocols.ru

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

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 ietf-ipr@ietf.org.

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

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


1BGP community.

2BGP route collector.

3Virtual Private Network – виртуальная частная сеть.

4Virtual Private LAN Service.

5Или «пирингом», от английского peering. Прим. перев.

6Interior Gateway Protocol – протокол внутренней маршрутизации.

7Маршрут ко всем.

8Двухоктетная расширенная группа уровня AS

9Regional Internet Registry

10Распределение в порядке поступления запросов.

11Данные этого реестра доступны по ссылке http://www.iana.org/assignments/bgp-data-collection-communities-std. Прим. перев.

12Global Routing Operations

13Этот документ заменен RFC 4271. Прим. перев.

15Эта статья доступна по ссылке http://rio.ecs.umass.edu/~gao/paper/imc_final.pdf.




RFC 4367 What’s in a Name: False Assumptions about DNS Names

Network Working Group                              J. Rosenberg, Ed.
Request for Comments: 4367                                       IAB
Category: Informational                                February 2006

 

 

Что в имени тебе моем? Ложные представления о доменных именах

What’s in a Name: False Assumptions about DNS Names

PDF

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

В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

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

Copyright (C) The Internet Society (2006).

Тезисы

Система доменных имен DNS1 обеспечивает важный для работы Internet сервис, отображая структурированные имена на различные типы данных (обычно адреса IP). Эти имена появляются в адресах электронной почты, идентификаторах ресурсов (URI2) и других идентификаторах прикладного уровня, которые часто представляются человеку. По этой причине существуют сильные притязания на приобретение имен, значимых для человека благодаря их связи с зарегистрированными торговыми знаками, именами компаний, типами служб и т. п. Такая тенденция таит в себе опасность – люди и автоматизированные системы, использующие такие имена, будут ассоциировать ту или иную семантику с некоторыми именами и, таким образом, делать предположения о том что сервис связан или может быть связан с хостами, которые ассоциируются с именами. Такие допущения часто являются ошибочными, приводя к путанице и возникновению проблем. В данном документе проводится детальное рассмотрение этого вопроса и даются рекомендации по решению проблем.

Оглавление

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

1. Введение

Система доменных имен DNS [1] обеспечивает важный для работы Internet сервис, отображая структурированные имена на различные типы данных. Наиболее часто эта система используется для получения IP-адреса хоста, связанного с именем этого хоста [2] [1] [3]. Однако эта система может использоваться и для получения другой информации – предположения могут быть сделаны почти обо всем, включая географическое положение [4].

Доменные имена чаще всего применяются в идентификаторах, используемых прикладными протоколами. К наиболее распространенным применениям относятся адреса электронной почты, идентификаторы ресурсов URI (такие, как HTTP URL [5]), RTSP3 URL [6] и SIP URI [7]. Эти идентификаторы являются уникальными, их указывают на визитных карточках, web-страницах, уличной рекламе и т. п. По этой причине существуют сильные притязания на приобретение имен, значимых для человека благодаря их связи с зарегистрированными торговыми знаками, именами компаний, типами служб и т. п. Такие идентификаторы могут использоваться в бизнесе, включая продвижение торговых марок (brand), рекламу и т. п.

Люди часто делают предположения о типе сервиса, который обеспечивается или может быть обеспечен хостом, связанным с определенным именем, на основе своих представлений и ожиданий, основанных на толковании этого имени. Это приводит к попыткам организаций регистрировать доменные имена на основе предполагаемых пользовательских ожиданий. Примером этого могут служить различные предложения для имен доменов верхнего уровня (TLD4), которые могут быть связаны с информацией «только для взрослых» (adult content) [8], запросы на создание TLD, связанных с мобильными устройствами и службами, и даже «разведение кроликов» (phishing attacks).

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

В главе 4 описаны некоторые возможные предположения, которые клиенты, серверы и люди могут делать в части толкования доменных имен. В этом контексте термин «предположение» (assumption) означает поведение, ожидаемое при обращении к сервису с данным именем даже если такое поведение явно не задано спецификациями протокола. Зачастую такие предположения включают игнорирование части спецификации на основе допущения, что клиенты и серверы используются в среде, требования которой более жестки, нежели требования спецификации. В главе 5 приводится обзор некоторых последствий таких ошибочных предположений. В общем случае такие последствия могут включать множество различных проблем взаимодействия, возникновение сложностей при работе пользователей и системные отказы. Глава 6 посвящена обсуждению причин, по которым такие предположения могут быть ошибочными изначально или становиться таковыми с течением времени. Чаще всего такие предположения становятся ошибочными в результате неожиданного изменения среды с течением времени, когда правильные допущения становятся ложными. Иногда предположения становятся ошибочными в результате того, что они были основаны на участии конкретного множества клиентов и серверов, а с течением времени появляются новые участники.

В главе 7 содержатся некоторые рекомендации. Эти рекомендации включают в себя инженерный опыт, накопленный за десятилетия разработки протоколов Internet. К таким рекомендациям относятся:

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

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

2. Аудитория

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

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

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

3. Модель использования DNS

                 +--------+
                 |        |
                 | Служба |
                 |  DNS   |
                 |        |
                 +--------+
                   ^   |
                   |   |
                   |   |
                   |   |
    /--\           |   |
   |    |          |   V
   |    |        +--------+                     +--------+
    \--/         |        |                     |        |
      |          |        |                     |        |
   ---+---       | Клиент |-------------------->| Сервер |
      |          |        |                     |        |
      |          |        |                     |        |
     /\          +--------+                     +--------+
    /  \
   /    \
Пользователь

Рисунок 1

На рисунке 1 показана простая концептуальная модель использования DNS приложениями. Пользователь приложения знает идентификатор для интересующей информации или службы. Этот идентификатор зачастую представляет собой URL или URI, содержащий доменное имя. Пользователь вводит идентификатор в клиентском приложении (например, набирая URL в строке ввода окна браузера). Клиент представляет собой автоматическую программно-аппаратную систему, которая контактирует с соответствующим сервером для того, чтобы обслужить запрос пользователя. Для того, чтобы сделать это, клиент обращается к серверу DNS для преобразования доменного имени из полученного идентификатора в адрес IP. После этого клиент обращается к серверу по полученному адресу. Эта простая модель применима к таким протоколам, как HTTP [5], SIP [7], RTSP [6], SMTP [9].

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

4. Возможные допущения

Каждый из трех элементов модели может делать множество различных ложных предположений.

4.1. Допущения пользователей

Множество возможных предположений пользователя практически не ограничено. Пользователи могут предполагать, что идентификатор HTTP URL, имеющий сходство с именем компании, приведет их на сервер этой компании. Они могут предполагать, что почтовый адрес из домена верхнего уровня .gov реально указывает на государственного служащего. Пользователи могут предполагать, что документы на web-сервере с домене TLD, выделенном для информации “только для взрослых” (например, .sex), действительно содержат информацию такого рода. Такие предположения неизбежны, все они могут оказаться ложными и не являются основной темой данного документа.

4.2. Допущения клиентов

Несмотря на то, что клиент является “автоматическим”, он может делать некоторые предположения, присущие человеку. Например, многие клиенты предполагают, что любой хост, имя которого начинается с www, является web-сервером, хотя такое предположение явно может быть ложным.

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

Алгоритм аутентификации: Несмотря на поддержку протоколом множества методов аутентификации, клиент может предположить, что сервер всегда поддерживает только один метод, который, согласно протоколу, является необязательным. Например, клиент SIP, контактирующий с сервером SIP в домене, который используется для идентификации мобильных устройств (например, www.example.cellular) может предположить, что сервер необязательный поддерживает метод AKA5 [10] на основании доменного имени, используемого для доступа к серверу. Другим примером может служить web-клиент, предполагающий, что сервер с именем https.example.com поддерживает защищенный протокол HTTP over TLS6 [16].

Форматы данных: Несмотря на поддержку протоколом множества форматов передачи данных клиенту от сервера, клиент может предположить использование какого-то одного метода взамен применения меток содержимого и возможностей согласования, обеспечиваемых нижележащим протоколом. Например, клиент RTSP может предположить, что все аудио-данные, получаемые с сайта media.example.cellular, используют узкополосное кодирование. В качестве другого примера можно рассмотреть почтового клиента, который полагает, что почтовый сервер с именем mail.example.cellular поддерживает только текстовый формат сообщений вместо проверки заголовков MIME [11] в сообщении для определения реального типа.

Расширения протокола: Клиент может попытаться работать с сервером, используя необязательные расширения протокола. Однако при этом вместо реализации требуемой логики выбора расширений (fallback logic), клиент может сделать ложное допущение о поддержке сервером того или иного расширения. Примером может служить клиент SIP, который требует гарантированных откликов на свои запросы (RFC 3262 [17]), предполагая, что это расширение поддерживается сервером с именем sip.example.telecom. Более того, клиент не будет реализовать возможность отказа от дополнительных расширений (fallback behavior), определенную в RFC 3262, поскольку предполагает, что все серверы, с которыми он будет взаимодействовать, находятся в том же домене и, следовательно, поддерживают это расширение. Однако, если это предположение окажется ошибочным, клиент не сможет сделать ни одного телефонного звонка.

Языки: Клиент может поддерживать средства обработки текста в зависимости от языка этого текста. Вместо определения языка на основе маркеров в сообщении от сервера клиент может делать предположения о языке на основе доменного имени. Такие предположения зачастую оказываются ложными. Например, клиент может предположить, что текст web-страницы с сервера в национальном (ccTLD) домене .de содержат текст на немецком языке и попытаться перевести этот текст на финский язык. Результат явно ошеломит пользователя, если реальный текст будет написан на французском языке. К несчастью описанное поведение клиентов иногда бывает вызвано тем, что сервер не указывает корректно язык документов, полагая, что это необязательно. Этот пример показывает, как ложные допущения могут создавать порочный круг.

4.3. Допущения серверов

Сервер, подобно клиенту, представляет собой автоматическую систему. Будем рассматривать для примера сервер www.company.cellular. Этот сервер может предполагать, что все подключающиеся к нему клиенты поддерживают конкретные возможности вместо того, чтобы использовать протоколы нижележащих уровней для определения возможностей клиентов. Допущения такого типа перечислены ниже.

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

Язык: Сервер может использовать тот или иной язык для представления документов на основе предположения, что обращающиеся к этому домену клиенты понимают этот язык, или предположения о том, что клиент с определенным адресом IP говорит на соответствующем языке.

Форматы данных: Сервер может предполагать, что клиент использует определенный набор типов MIME и способен передавать только такие типы. При генерации содержимого в протокольном отклике сервер игнорирует заголовки согласования содержимого, которые могли присутствовать в запросе. Например, сервер может игнорировать тег Accept HTTP и передавать изображение в том или ином специфическом формате.

Расширения протокола: Сервер может предполагать, что клиент поддерживает то или иное необязательное расширение протокола и не поддерживать согласование, которое необходимо, если клиент не поддерживает это расширение.

Характеристики клиента: Сервер может делать некоторые предположения о физических характеристиках своих клиентов (объем памяти, производительность процессора, размер экрана, глубина цвета, указательное устройство и т. п.). Основываясь на таких допущениях, сервер может выбирать свое поведение при обработке запроса. Например, web-сервер может всегда предполагать, что клиент подключен через сотовый телефон и, следовательно, возвращать содержимое с минимальным количеством графики и иными особенностями, используемые в подобных случаях.

5. Последствия ложных допущений

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

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

Системные сбои: В отдельных случаях клиент или сервер некорректно интерпретирует протокольные операции и это открывает дефекты реализации. Дефект приводит к постоянному (до сброса с участием человека) или временному полному отказу системы или выходу из строя отдельных компонент. Если отказ возникает на сервере, проблема коснется не только клиента, вызвавшего этот отказ, но и всех прочих клиентов, которые будут обращаться к серверу. Например, если web-сервер предполагает, что информация, полученная им от клиента (например, изображение с цифровой камеры) относится к определенному типу, и всегда передает изображение в кодек для декомпрессии прежде, чем записать его, работа кодека может завершиться отказом при сжатии исходного изображения с использованием неподдерживаемого кодеком формата. Такая проблема может возникать даже при корректном значении Content-Type, если сжатый битовый поток содержит ошибки. Ложные допущения увеличивают вероятность отказа.

Негативный опыт пользователей: В таких случаях клиент и сервер могут взаимодействовать, но пользователь приобретает негативный опыт. Например, если клиент на ПК подключается к web-серверу, предназначенному для работы с мобильными устройствами, содержимое полученных документов может оказаться неудобочитаемым на экране ПК, Другим примером может служить обращение клиента к потоковому сервису, при котором информация передается в низкоскоростном варианте, хотя кодек клиента может поддерживать более высокое качество. Еще одним примером является ситуация, когда пользователь желает обращаться к сервису с ПК и мобильного устройства, используя общую адресную книгу (эта книга доступна с разных устройств). В таких случаях пользователю нужно создавать две записи в адресной книге и использовать при обращении к серверу запись, соответствующую выбранному для работы с сервером устройству. Такие ситуации оставляют у пользователя негативные впечатления.

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

6. Причины ложных допущений

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

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

6.1. Эволюция

Internet и устройства, используемые для доступа в сеть постоянно изменяются и, зачастую, весьма быстро. К сожалению существует тенденция строить «здесь и сейчас», не задумываясь о будущем. Многие из перечисленных выше предположений основываются на характеристиках сегодняшних клиентов и серверов. Поддержка специфических протоколов, методов аутентификации или содержимого основывается на сегодняшних стандартах и устройствах. Хотя такой подход является правильным для большинства случаев, это не может происходить всегда. Прекрасным примером являются мобильные устройства. Сервер, обслуживающий домен, к которому обращаются такие устройства, может делать предположения о протоколах, расширениях, размере экранов, механизмах защиты или производительности процессоров таких устройств. Однако все эти характеристики могут и будут меняться с течением времени.

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

6.2. Распространение информации

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

Проблема состоит в том, что это допущение обычно является ложным. Сеть Internet является глобальной, так же, как служба доменных имен DNS. Не существует технических барьеров, отделяющих членов группы (community) от всех остальных. С учетом распространения информации по сети Internet очевидно, что к серверу время от времени будут обращаться клиенты, которые не входят в предполагаемую группу. Повсеместное присутствие доменных имен в различных форматах URI, вкупе с простотой распространения URI делает процесс распространения информации о доменных именах чрезвычайно быстрым. Более того, глобальный характер DNS с единственным корнем системы имен [12] делает возможным для клиентов, не включенных в группу поиск, нахождение и использование таких “специальных” доменных имен.

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

6.3. Передача полномочий

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

Использование доменных имен с удобной для человека семантикой ведет к регистрации множества доменов, в которых может быть реализован тот или иной конкретный сервис. Например, сервис-провайдер по имени example может зарегистрировать и развернуть свои службы в доменах example.com, example.net и, в общем случае в example.foo, где foo может быть любым корректным TLD. Это, подобно передаче полномочий, приводит к росту числа доменов и осложняет централизованный контроль.

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

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

Более детальное рассмотрение некорректности допущений в результате передачи полномочий приводится в параграфе 4.1.3 документа [8] и параграфе 3.3 документа [20].

Как результат слабого контроля за соблюдением единой политики при передаче полномочий является то, что если пользователь или клиент может предположить некоторые свойства, связанные с TLD (например, .wifi), такие свойства могут теряться при передаче полномочий и не поддерживаться конкретным сервером в данном домене верхнего уровня. Например, в store.chain.company.provider.wifi может быть 4 уровня передачи полномочий от .wifi и достаточно очевидно, что при отсутствии должных усилий со стороны держателя .wifi, некоторые свойства могут отсутствовать на нижних уровнях. Причинами отсутствия этих свойств могут быть человеческие ошибки или осознанный отказ от соответствия общей политике.

6.4. Мобильность

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

6.5. Человеческие ошибки

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

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

7. Рекомендации

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

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

Согласование возможностей. Многие протоколы поддерживают механизмы согласования возможностей. Например, схема согласования содержимого определена для протоколов, использующих MIME [13] [14] [15]. Протокол SIP позволяет клиентам согласовать тип среды, используемой в multimedia-сеансе, а также параметры протокола. HTTP позволяет клиентам согласовать тип информации, возвращаемой по запросу. Когда такие возможности поддерживаются протоколом, клиентам и серверам следует использовать эти возможности и не делать предположений о поддерживаемых другой стороной возможностях. Разработчикам протоколов следует включать механизмы согласования в тех случаях, когда предполагается возможность изменения способов использования протокола.

Требовательность к себе и великодушие к другим [18]. Эта аксиома протоколов Internet применима и для рассматриваемой проблемы. Разработчикам следует быть готовыми к приему всего, что протокол позволяет передать другой стороне и не ограничиваться приемом лишь того, что хочется получить.

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

8. Примечания к RFC 2219 и RFC 2782

В соответствии с данными здесь определениями предположений, поведение, обусловленное записями DNS, также является основанным на предположении. RFC 2219 [19] определяет общепринятые (well-known) псевдонимы, которые могут использоваться при создании доменных имен, используемых для доступа к общепринятым службам в домене. Этот подход был впоследствии расширен путем определения нового типа записи о ресурсах SRV [2], который используется для указания того или иного типа сервиса, работающего на сервере в данном домене. Оба эти механизма могут быть полезными намеками на сервис, реализованный в домене, но эти намеки могут стать основой для ложных допущений. Однако причины, по которым такие допущения могут быть ложными, отличаются от рассмотренных выше.

Клиент, предполагающий, что хост ftp.example.com является сервером FTP, может ошибаться по той причине, что соглашение об именах RFC 2219 может быть неизвестно владельцу домена или не выполняться им. В соответствии с RFC 2782 запись SRV для того или иного сервиса включается только по желанию администратора домена и клиент, делающий предположения о том, что хост обеспечивает некий сервис, может ошибаться в результате допущенной человеком ошибки. В этом случае ошибочность допущения менее очевидна, но, тем не менее, оно может быть ошибочным.

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

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

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

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

IAB выражает свою благодарность John Klensin, Keith Moore и Peter Koch за их комментарии к документу.

11. Члены IAB

Членами IAB7 на момент написания этого документа были:

Bernard Aboba

Loa Andersson

Brian Carpenter

Leslie Daigle

Patrik Faltstrom

Bob Hinden

Kurtis Lindqvist

David Meyer

Pekka Nikander

Eric Rescorla

Pete Resnick

Jonathan Rosenberg

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

[1] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[2] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, «A Means for Expressing Location Information in the Domain Name System», RFC 1876, January 1996.

[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[6] Schulzrinne, H., Rao, A., and R. Lanphier, «Real Time Streaming Protocol (RTSP)», RFC 2326, April 1998.

[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, June 2002.

[8] Eastlake, D., «.sex Considered Dangerous», RFC 3675, February 2004.

[9] Klensin, J., «Simple Mail Transfer Protocol», RFC 2821, April 2001.

[10] Niemi, A., Arkko, J., and V. Torvinen, «Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)», RFC 3310, September 2002.

[11] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[12] Internet Architecture Board, «IAB Technical Comment on the Unique DNS Root», RFC 2826, May 2000.

[13] Klyne, G., «Indicating Media Features for MIME Content», RFC 2912, September 2000.

[14] Klyne, G., «A Syntax for Describing Media Feature Sets», RFC 2533, March 1999.

[15] Klyne, G., «Protocol-independent Content Negotiation Framework», RFC 2703, September 1999.

[16] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[17] Rosenberg, J. and H. Schulzrinne, «Reliability of Provisional Responses in Session Initiation Protocol (SIP)», RFC 3262, June 2002.

[18] Braden, R., «Requirements for Internet Hosts – Communication Layers», STD 3, RFC 1122, October 1989.

[19] Hamilton, M. and R. Wright, «Use of DNS Aliases for Network Services», BCP 17, RFC 2219, October 1997.

[20] Faltstrom, P., «Design Choices When Expanding DNS», Work in Progress, June 2005.

Адрес автора

Jonathan Rosenberg, Editor

IAB

600 Lanidex Plaza

Parsippany, NJ 07054

US

Phone: +1 973 952-5000

EMail: jdrosen@cisco.com

URI: http://www.jdrosen.net


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

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

nmalykh@protocols.ru

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

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 ietf-ipr@ietf.org.

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

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


1Domain Name System

2Uniform Resource Identifier – типовой идентификатор ресурса

3Real Time Streaming Protocol – потоковый протокол в реальном масштабе времени.

4Top-Level Domain

5Authentication and Key Agreement – аутентифкация и согласование ключей.

6Transport Layer Security – защита транспортного уровня.

7Internet Architecture Board – комитет по архитектуре Internet.




RFC 4360 BGP Extended Communities Attribute

Network Working Group                                      S. Sangli
Request for Comments: 4360                                 D. Tappan
Category: Standards Track                              Cisco Systems
                                                          Y. Rekhter
                                                    Juniper Networks
                                                       February 2006

Атрибут BGP Extended Communities

BGP Extended Communities Attribute

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

В этом документе описан атрибут Extended Communities1 протокола BGP-4. Данный атрибут обеспечивает механизм установки меток для информации, передаваемой в BGP-4. Эти метки могут использоваться для контроля за распространением информации и других приложений.

1. Введение

Атрибут Extended Communities обеспечивает механизм включения меток для информации, передаваемой протоколом BGP-4 [BGP-4]. Новый атрибут обеспечивает две новых возможности по сравнению с прежним атрибутом BGP Community [RFC1997]:

  • расширенный диапазон, обеспечивающий возможность выделения групп для широкого спектра задач без опасения перекрытия групп;
  • добавление поля Type (тип) обеспечивает структурирование пространства групп.

Добавление структуры делает возможным построение основанных на правилах приложений, для которых используются группы. Например, кто-либо может отфильтровывать все группы определенного типа или разрешать только определенные значения для того или иного типа групп. Обеспечивается также возможность указать передается ли определенная группа через границу автономной системы (AS). Без использования структуры такая задача может быть решена только путем явного перечисления всех значений групп, которые разрешено или запрещено передавать узлам BGP в соседних AS на основе свойства транзитивности.

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

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

2. Атрибут BGP Extended Communities

Атрибут Extended Communities относится к числу транзитивных (переходных) необязательных атрибутов BGP и имеет код типа (Type Code) 16. Атрибут состоит из набора «расширенных групп». Все маршруты с атрибутом Extended Communities принадлежат группам, указанным в этом атрибуте.

Каждая группа Extended Community представляется 8-октетным значением, формат которого показан на рисунке.

  • поле Type — 1 или 2 октета;
  • поле Value – оставшиеся октеты.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type high    |  Type low(*)  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Type

Вводятся два класса поля типа (Type) – обычный (Regular) и расширенный (Extended) тип.

Размер поля Type для типа Regular составляет 1 октет, а для типа Extended — 2 октета.

Значение старшего октета поля Type определяет имеет расширенная группа тип Regular или Extended. Класс типа (Regular или Extended) не кодируется в структуре самого типа. Класс типа задается в документе, который определяет данный тип, и в реестре IANA.

Формат старшего октета поля Type показан на рисунке.

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |I|T|           |
            +-+-+-+-+-+-+-+-+

I – флаг IANA

0 – тип выделяется IANA с использованием правила First Come First Serve2.

1 – часть пространства этого поля Type представляет собой тип, распределяемый IANA на основе правил Standard Action3 или Early IANA Allocation4. Остальное пространство данного поля Type оставлено для экспериментального использования.

T – бит транзитивности (Transitive)

0 – группа передается между AS;

1 – группа не передается между AS.

Оставшиеся 6 битов показывают структуру группы.

Поле Value

Кодирование значений поля Value определяется типом группы, заданным в поле Type.

Две расширенных группы трактуются как одинаковые только при полном совпадении всех 8 октетов.

Два элемента пары <Type, Value> следует перечислять для задания любого значения группы. Оставшиеся октеты интерпретируются в зависимости от значения поля Type.

3. Определенные типы BGP Extended Community

В этой главе определено несколько расширенных типов и форматы поля Value для этих типов. Введенные здесь типы обеспечивают “шаблоны”, каждый из которых идентифицируется старшим октетом поля Type, а младший октет этого поля (sub-type) используется для индикации конкретного типа расширенной группы.

3.1. Двухоктетная расширенная группа уровня AS

Это расширенный тип с полем Type из двух октетов и шестиоктетным полем Value.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x00 or 0x40  |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Administrator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Значение старшего октета данного расширенного типа может быть 0x00 или 0x40. Младший октет поля типа используется для индикации субтипа (Sub-Type).

Поле Value состоит из двух субполей:

Global Administrator (глобальный администратор) — 2 октета

Это субполе содержит номер автономной системы, выделенный IANA.

Local Administrator (локальный администратор) — 4 октета

Организация, указанная номером AS в субполе Global Administrator, может кодировать в этом субполе любую информацию. Формат и значение данного субполя следует задавать при определении субтипа группы.

3.2. Двухоктетная расширенная группа, связанная с адресом IPv4

Это расширенный тип с полем Type из двух октетов и шестиоктетным полем Value.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x01 or 0x41  |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |    Local Administrator        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Значение старшего октета данного расширенного типа может быть 0x01 или 0x41. Младший октет поля типа используется для индикации субтипа.

Поле Value состоит из двух субполей:

Global Administrator (глобальный администратор) — 4 октета

Это субполе содержит индивидуальный (unicast) адрес Ipv4, выделенный одним из регистраторов Internet.

Local Administrator (локальный администратор) — 2 октета

Организация, которой выделен адрес Ipv4, указанный в поле Global Administrator, может кодировать в этом субполе любую информацию. Формат и значение данного субполя следует задавать при определении субтипа группы.

3.3. Opaque Extended Community

Это расширенный тип с полем Type из двух октетов и шестиоктетным полем Value.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x03 or 0x43  |   Sub-Type    |                Value          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Значение старшего октета данного расширенного типа может быть 0x03 или 0x43. Младший октет поля типа используется для индикации субтипа.

Это базовый тип расширенной группы. Значения поля Sub-Type, которое определяет трактовку поля Value, выделяются IANA.

4. Route Target Community

Route Target Community идентифицирует один или множество маршрутизаторов, которые могут получить набор маршрутов (содержащий данный атрибут Community), переносимый BGP. Этот атрибут передается через границы AS.

Route Target Community относится к расширенному типу.

Значение старшего октета поля Type для Route Target Community может быть 0x00, 0x01 или 0x02. Значение младшего октета поля Type для этой группы — 0x02.

Когда старший октет поля Type имеет значение 0x00 или 0x02, субполе Local Administrator содержит значение из пространства, администрируемого организацией, для которой соответствующим органом был выделен номер автономной системы, указанный в поле Global Administrator.

Когда старший октет поля Type имеет значение 0x01, субполе Local Administrator содержит значение из пространства, администрируемого организацией, для которой соответствующим органом был выделен адрес IP, указанный в субполе Global Administrator.

Один из вариантов использования Route Target Community описан в [RFC4364].

5. Route Origin Community

Route Origin Community идентифицирует один или множество маршрутизаторов, которые поместили набор маршрутов (содержащий данный атрибут Community) в BGP. Этот атрибут передается через границы AS.

Route Origin Community относится к расширенному типу.

Старший октет поля Type для Route Origin Community может принимать значение 0x00, 0x01 или 0x02. Значение младшего октета поля Type для этой группы — 0x03.

Когда старший октет поля Type имеет значение 0x00 или 0x02, субполе Local Administrator содержит значение из пространства, администрируемого организацией, для которой соответствующим органом был выделен номер автономной системы, указанный в поле Global Administrator.

Когда старший октет поля Type имеет значение 0x01, субполе Local Administrator содержит значение из пространства, администрируемого организацией, для которой соответствующим органом был выделен адрес IP, указанный в субполе Global Administrator.

Один из вариантов использования Route Target Community описан в [RFC4364].

6. Работа с расширенными группами

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

Атрибут Extended Community недопустимо использовать для изменения процесса выбора лучшего пути BGP такими способами, которые ведут к образованию маршрутных петель.

Узел BGP, получивший маршрут без атрибута Extended Communities, может добавить такой атрибут в конце маршрута (append) при распространении этого маршрута своим партнерам.

Узел BGP, получивший маршрут с атрибутом Extended Communities, может изменить этот атрибут в соответствии с локальной политикой.

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

Если маршрут содержит нетранзитивную расширенную группу, то перед анонсированием такого маршрута через границу AS эту группу следует удалить из маршрута. Однако группу не нужно удалять при анонсировании маршрута через границу конфедерации BGP.

Маршрут может содержать одновременно атрибут BGP Communities, определенный в [RFC1997]), и атрибут Extended BGP Communities. В таких случаях атрибут BGP Communities обрабатывается в соответствии с [RFC1997], а Extended BGP Communities – в соответствии с настоящим документом.

7. Согласование с IANA

Все атрибуты BGP Extended Communities содержат поле Type. Агентство IANA создало реестр «BGP Extended Communities Type», который будет поддерживаться IANA.

Поле Type может быть обычным (regular) или расширенным (extended). Для обычного поля Type агентство IANA выделяет 8-битовое значение. а для расширенного — 16-битовое.

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

Поле Type показывает является атрибут Extended Community переходным или непереходным. Будущие запросы на выделение значений Type должны указывать для какого атрибута (переходного или непереходного) Extended Community предназначено это значение Type.

Выделение значений будет осуществляться в соответствии с процессом Standards Action, определенным в [RFC2434], процессом Early IANA Allocation, определенным в [RFC4020] или правилом First Come First Served, которое определено в [RFC2434].

В приведенной ниже таблице указаны диапазоны для распределения значений поля Type.

Тип Правила распределения

Standard Action
Early IANA Allocation

First Come First Served

Обычные, переходные

0x90 — 0xbf

0x00 — 0x3f5

Обычные, непереходные

0xd0 — 0xff

0x40 — 0x7f

Расширенные, переходные

0x9000 — 0xbfff

0x0000 — 0x3fff

Расширенные, непереходные

0xd000 — 0xffff

0x4000 — 0x7fff

При распределении выделяется имя и значение.

Значения поля Type из диапазонов 0x80 — 0x8f и 0xc0 — 0xcf для обычного типа и диапазонов 0x8000 — 0x8fff и 0xc000 — 0xcfff – для расширенного, предназначены для экспериментального использования, как определено в RFC 3692.

Этот документ определяет класс расширенных групп, называемых двухоктетными расширенными группами уровня AS (AS specific extended community), для которых IANA поддерживает реестр Two-octet AS Specific Extended Community6. Все группы этого класса относятся к расширенному типу. Выделение значений для этого класса будет происходить согласно правилу «First Come First Served»7, определенному в [RFC2434]. Значения Type для переходных групп этого класса относятся к диапазону 0x0000 — 0x00ff, а для непереходных – к диапазону 0x4000 — 0x40ff. При распределении выделяется имя и значение.

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

Имя Значение поля Type
two-octet AS specific Route Target 0x0002
two-octet AS specific Route Origin 0x0003

Данный документ определяет класс расширенных групп, называемых IPv4 address specific extended8, для которых IANA поддерживает реестр «IPv4 Address Specific Extended Community»9. Все группы этого класса относятся к расширенному типу. Выделение значений для этого класса будет происходить согласно правилу «First Come First Served», определенному в [RFC2434]. Значения Type для переходных групп этого класса относятся к диапазону 0x0100 — 0x01ff, а для непереходных – к диапазону 0x4100 — 0x41ff. При распределении выделяется имя и значение.

В таблице показаны значения, выделенные данным документом для класса двухоктетных расширенных групп, связанных с адресом IPv4.

Имя Значение поля Type
IPv4 address specific Route Target 0x0102
IPv4 address specific Route Origin 0x0103

Данный документ определяет расширенные группы, названные Opaque Extended Community, для которых IANA поддерживает реестр «Opaque Extended Community»5. Все группы этого класса относятся к расширенному типу. Выделение значений для этого класса будет происходить согласно правилу «First Come First Served», определенному в [RFC2434]. Значения Type для переходных групп этого класса относятся к диапазону 0x0300 — 0x03ff, а для непереходных – к диапазону 0x4300 — 0x43ff. При распределении выделяется имя и значение.

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

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

Причастность данного расширения BGP к вопросам безопасности подобна BGP Communities [RFC1997].

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

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

Спасибо John Hawkinson, Jeffrey Haas, Bruno Rijsman, Bill Fenner и Alex Zinin за их предложения и отклики.

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

[BGP-4] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, August 1996.

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

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC4020] Kompella, K. and A. Zinin, «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 4020, February 2005.

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

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, February 2006.

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

Srihari R. Sangli

Cisco Systems, Inc.

EMail: rsrihari@cisco.com

Dan Tappan

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA 01824

EMail: tappan@cisco.com

Yakov Rekhter

Juniper Networks, Inc.

1194 N. Mathilda Ave

Sunnyvale, CA 94089

EMail: yakov@juniper.net


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

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

nmalykh@protocols.ru

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

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 ietf-ipr@ietf.org.

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

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


1Расширенные группы

2Распределение в порядке очередности поступления запросов.

3Требуется стандартизация.

4Предварительное распределение до стандартизации.

5В оригинале ошибочно указан диапазон 0x00 – x3f. Прим. перев.

6Этот реестр доступен по ссылке http://www.iana.org/assignments/bgp-extended-communities. Прим. перев.

7Распределение в порядке очередности поступления запросов.

8Двухоктетная расширенная группа, связанная с адресом IPv4

9Этот реестр доступен по ссылке http://www.iana.org/assignments/bgp-extended-communities. Прим. перев.