RFC 8060 LISP Canonical Address Format (LCAF)

Опубликовано 24.02.2017 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 8060                                   lispers.net
Category: Experimental                                          D. Meyer
ISSN: 2070-1721                                                  Brocade
                                                             J. Snijders
                                                                     NTT
                                                           February 2017

LISP Canonical Address Format (LCAF)

Канонический формат адресов LISP (LCAF)

PDF

Аннотация

Этот документ определяет канонический формат кодирования адресов, используемых в управляющих сообщениях протокола LISP, и кодирования ключей поиска для системы сопоставления LISP (Mapping Database System).

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

Документ не содержит стандарта Internet и публикуется для проверки, экспериментальной реализации и оценки.

Документ определяет экспериментальный протокол для сообщества Internet. Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все документы, одобренные IESG претендуют на статус Internet Standard. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc8060.

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

Copyright (c) 2017. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Архитектура и протокол LISP [RFC6830] добавили два новых пространства номеров – идентификаторы конечных точек (Endpoint Identifier или EID) и локаторы маршрутизации (Routing Locator – RLOC). Для обеспечения гибкости имеющимся и будущим приложениям эти значения могут кодироваться в управляющих сообщениях LISP с использованием базового синтаксиса, включающего идентификатор семейства адресов (Address Family Identifier или AFI), размер и значение.

В настоящее время AFI включают адреса IPv4 и IPv6, форматируемые в соответствии с кодом из реестра Address Family Numbers [AFN], как показано ниже.

IPv4

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            AFI = 1            |       IPv4 Address ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ...  IPv4 Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            AFI = 2            |       IPv6 Address ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ...  IPv6 Address  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ...  IPv6 Address  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ...  IPv6 Address  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ...  IPv6 Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В этом документе описаны определённые к настоящему моменту AFI, которые в LISP используются вместе с их кодами, и введён канонический формат адреса LISP (LISP Canonical Address Format или LCAF), который может служить для определения специфичных для LISP кодировок произвольных AFI.

Конкретные детали применения типов LCAF, определённых в этом документе, могут быть представлены в документах по реализующим их вариантам применения. Один и тот же LCAF Type может использоваться в нескольких документах о вариантах применения. Как экспериментальная спецификация, эта работа по определению не полна.

Типы LCAF, определённые в этом документе предназначены для поддержки экспериментов и осторожного применения в автономных средах во поддержку соответствующих документов о применении. Документ назначает исходный набор утвержденных LCAF Type (зарегистрированных в IANA) и дополнительных, ещё не одобренных LCAF Type [RFC6830]. Неодобренное кодирование LCAF задано для поддержки дальнейших исследований и экспериментов.

2. Терминология

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

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

2.2. Определения терминов

Address Family Identifier (AFI) – идентификатор семейства адресов

Термин, применяемый для описания кодирования адреса в пакете. Семейства адресов определены для IPv4 и IPv6. Подробности приведены в [AFN] и [RFC3232]. Резервное значение AFI = 0 служит в этой спецификации для указания незаданного кодирования, где адрес имеет нулевой размер (нет адреса).

Unspecified Address Format – незаданный формат адреса

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            AFI = 0            |      <нет адреса>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Endpoint ID (EID) – идентификатор конечной точки

32-битовое (IPv4) или 128-битовое (IPv6) значение, используемое в полях адресов отправителя и получателя в первом (внутреннем) заголовке LISP в пакете. Хост получает EID адресата так же, как это делается сегодня, например, через запрос DNS или обмен SIP. EID источника получается через имеющиеся механизмы, применяемые для установки «локального» IP-адреса хоста. EID выделяется хосту из префикса EID, связанного с сайтом, где размещается хост. EID может использоваться хостом для указания другого хоста.

Routing Locator (RLOC) – локатор маршрутизации

Адрес IPv4 или IPv6 выходного маршрутизатора туннеля (Egress Tunnel Router или ETR). Это результат поиска в сопоставлении EID с RLOC. EID отображается на один или несколько локаторов RLOC. Обычно RLOC выделяются из топологически агрегируемых блоков, выделенных сайту в каждой точке присоединения к глобальной сети Internet. Топология определяется связностью сетей провайдеров и RLOC можно считать выделенными провайдером (Provider-Assigned или PA) адресами. Одному или нескольким устройствам ETR на сайте может быть выделено множество RLOC.

3. Каноническое кодирование адресов в LISP

Агентство IANA выделило значение AFI = 16387 (0x4003) для формата LCAF. Эта спецификация задаёт формат кодирования канонических адресов LISP (LISP Canonical Address или LCA). В этом параграфе определены все типы, для которых запрошено исходное назначение в реестре LISP-LCAF. Список типов представлен в разделе 7. Взаимодействие с IANA.

Определения AFI в [AFN] лишь назначают коды для самих значений AFI. Размер адреса или следующего за ним элемента не задан и предполагается основанным на общепринятом опыте. Для использования в LISP определений LCAF из этого документа размер основанного на AFI адреса задан в документе. При задании новых определений LCAF в других документах по применению размер основанного на AFI адреса для новых адресов с кодированием AFI следует задавать в таких документах.

За первыми 6 байтами LCA следует переменное число полей переменного размера, как показано на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             . . .                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rsvd1/Rsvd2

Эти 8-битовые поля зарезервированы на будущее и должны содержать значение 0 при передаче, а при получении – игнорироваться.

Flags

Это 8-битовое поле рассчитано на будущее. В настоящее время устанавливается в 0 при передаче и игнорируется при получении.

Type

Это 8-битовое поле относится к кодированию LCAF. Ниже указаны обобренные и не одобренные значения типов. Дополнительные сведения приведены в разделе 5. Экспериментальное использование канонических адресов LISP.
Type 0: Null Body
Type 1: AFI List
Type 2: Instance ID
Type 3: AS Number
Type 4: Application Data (не утверждён, см. 5. Экспериментальное использование канонических адресов LISP)
Type 5: Geo-Coordinates
Type 6: Opaque Key (не утверждён, см. 5. Экспериментальное использование канонических адресов LISP)
Type 7: NAT-Traversal
Type 8: Nonce Locator (не утверждён, см. 5. Экспериментальное использование канонических адресов LISP)
Type 9: Multicast Info
Type 10: Explicit Locator Path
Type 11: Security Key
Type 12: Source/Dest Key
Type 13: Replication List Entry
Type 14: JSON Data Model (не утверждён, см. 5. Экспериментальное использование канонических адресов LISP)
Type 15: Key/Value Address Pair (не утверждён, см. раздел 5)
Type 16: Encapsulation Format (не утверждён, см. раздел 5)

Length

Это 16-битовое поле указывает размер в байтах всего содержимого LCA, после поля Length. При использовании AFI минимальный размер адреса в кодировке LCAF составляет 8 байтов и Length = 0. Эти 8 байтов включают поля AFI, Flags, Type, Rsvd1, Rsvd2, Length. Когда AFI нет вместе с закодированным адресом в управляющем сообщении, минимальный размер адреса составляет 6 байтов и Length = 0. Эти 6 байтов включают поля Flags, Type, Rsvd1, Rsvd2, Length.

В [RFC6830] указано, что записи RLOC, основанные на адресе IP, сортируются при кодировании в управляющих сообщениях, поэтому набор локаторов (locator-set) имеет согласованный порядок во всех xTR для данного EID. Порядок сортировки определяется ключом {afi, адрес RLOC}. При кодировании RLOC на основе адреса IP в LCAF ключом сортировки является {afi, LCAF-Type}. Поэтому при смешении в locator-set записей AFI и LCAF они упорядочиваются по AFI (от меньшего к большему).

4. Применение канонических адресов LISP

В следующих параграфах даны определения LCAF для одобренных значений Type исходного набора.

4.1. Сегментация с использованием LISP

Когда несколько организаций на сайте LISP использует приватные адреса [RFC1918] как префиксы EID, адресные пространства организаций должны быть разделены по причине возможного дублирования адресов. Поле Instance ID в кодировании адреса позволяет сделать весь адрес на основе AFI уникальным.

Другим применением Instance ID в LCAF является создание нескольких сегментированных VPN внутри сайта LISP, когда желательно сохранить подсети, основанные на префиксах EID.

Instance ID LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 2    | IID mask-len  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Instance ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |         Address  ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IID mask-len

Если AFI = 0, этот формат не кодирует расширенный префикс EID, а представляет лишь диапазон Instance ID, где IID mask-len указывает число старших битов в поле Instance ID для диапазона. Младшие биты Instance ID должны иметь значение 0.

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Instance ID

Младшие 24 бита, которые могут войти в заголовок данных LISP, когда установлен бит I (см. [RFC6830]). Причина разницы в размере заключается в том, что максимальное число экземпляров, поддерживаемых системой отображения, составляет 232, а место в заголовке данных LISP экономится. С этим связано ограничение максимального числа экземпляров на xTR значением 224. Если на xTR настроено множество Instance ID с совпадающими старшими 8 битами, младшие 24 бита должны быть уникальными.

AFI = x

x может быть любым значением AFI из [AFN].

Тип LCA можно применять для кодирования адресов EID и RLOC.

При использовании в качестве ключа поиска EID рассматривается в системе сопоставления как extended-EID. Это кодирование применяется в записях EID сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании дерева делегированных баз данных (LISP Delegated Database Tree или LISP-DDT) [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID.

4.2. Передача номеров AS в базе сопоставлений

При сохранении номера автономной системы (Autonomous System или AS) в базе данных системы сопоставления LISP (Mapping Database System) для политики или документирования его можно закодировать в LCA.

AS Number LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 3    |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AS Number                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |         Address  ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

AS Number

32-битовый номер AS, который выделен для последующего EID или RLOC.

AFI = x

x может быть любым значением AFI из [AFN].

Тип AS Number LCAF можно применять для кодирования адресов EID и RLOC. Первый служит для описания номера AS LISP-ALT префикса EID сайта для которого запись передаётся. Второй применяется для описания AS, которая содержит префиксы на основе RLOC в базовой системе маршрутизации.

Это кодирование может применяться в записях EID или RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании LISP-DDT [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID.

4.3. Назначение географических координат адресам локаторов

Если ETR хочет передать сообщение Map-Reply, описывающее географические координаты (Geo-Coordinates) для каждого локатора в своём locator-set, он может использовать тип Geo-Coordinates LCAF для передачи сведений о физическом местоположении. Координаты задаются с использованием эталонной системы WGS 84 (World Geodetic System 1984) [WGS-84].

Geo-Coordinates LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 5    |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|     Latitude Degrees        |    Minutes    |    Seconds    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|     Longitude Degrees       |    Minutes    |    Seconds    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Altitude                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |         Address  ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

N

1 означает север, все остальное – юг.

Latitude Degrees

Значение широты в градусах (0 – 90) относительно экватора (северная или южная полусфера).

Latitude Minutes

Минуты широты (0 – 59).

Latitude Seconds

Секунды широты (0 – 59).

E

1 означает восток, все остальное – запад.

Longitude Degrees

Значение долготы в градусах (0 – 180) относительно нулевого меридиана (Prime Meridian).

Longitude Minutes

Минуты долготы (0 – 59).

Longitude Seconds

Секунды долготы (0 – 59).

Altitude

Высота над уровнем моря в метрах, указанная целочисленным дополнением до 2 со знаком. Значение 0x7fffffff указывает неизвестную высоту.

AFI = x

x может быть любым значением AFI из [AFN].

Тип Geo-Coordinates LCAF может применяться для кодирования адресов EID и RLOC. При использовании для EID можно указать физическое местоположение EID вместе с топологическим размещением, наблюдая locator-set.

Это кодирование может применяться в записях EID или RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании LISP-DDT [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID.

Использование кодирования Geo-Coordinates LCAF может вызывать проблемы приватности, поскольку сведения о расположении могут быть приватными, например при размещении устройства в жилище. Поэтому такое кодирование не следует применять, пока оно не требуется для работы развёртывания LISP. До принятия решения о применении кодирования следует убедиться, что EID использует подходящие правила для контроля передаваемой информации.

4.4. Варианты работы через NAT

Когда система LISP передаёт сведения о глобальном адресе и отображённом порте через устройство NAT, применяется тис NAT-Traversal LCAF (см. [NAT-LISP]).

NAT-Traversal LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 7    |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       MS UDP Port Number      |      ETR UDP Port Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |  Global ETR RLOC Address  ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |       MS RLOC Address  ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          | Private ETR RLOC Address  ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |      RTR RLOC Address 1 ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |      RTR RLOC Address k ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

MS UDP Port Number

Номер порта UDP на Map-Server (4342).

ETR UDP Port Number

Номер порта, возвращённый системе LISP, который был скопирован из порта источника в пакете, прошедшем NAT.

AFI = x

x может быть любым значением AFI из [AFN].

Global ETR RLOC Address

Заведомо уникальный в глобальном масштабе адрес, созданный функциональность работы через NAT в маршрутизаторе LISP.

MS RLOC Address

Адрес Map-Server, используемый в RLOC получателя пакета, прошедшего через NAT.

Private ETR RLOC Address

Заведомо приватный адрес, помещённый в LCAF маршрутизатором LISP на приватной стороне устройства NAT.

RTR RLOC Address

Адрес инкапсуляции, применяемый ITR или PITR3, находящимся за NAT. Известно, что для этого адреса имеется состояние NAT, чтобы пакеты могли проходить с этого адреса маршрутизатору LISP ETR, расположенному за NAT. В этом наборе полей может указываться один или несколько адресов маршрутизаторов NAT RTR4 [NAT-LISP]. Число RTR определяется при разборе каждого поля. Если RTR не указаны, поля RTR можно опустить и отразить в поле размера LCAF или можно использовать AFI = 0 для указания отсутствия RTR.

Это кодирование может применяться в сообщениях Info-Request и Info-Reply. Система сопоставления не хранить эти сведения, их используют xTR и Map-Server для передачи приватного и публичного адреса при работе через NAT или межсетевые экраны.

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

4.5. Сведения о принадлежности к Multicast-группе

Сведения о Multicast-группах могут публиковаться в базе сопоставлений. Поиск по групповому адресу EID может возвращать список групповых или индивидуальных адресов RLOC для репликации. Назначение этого типа индивидуальной репликации состоит в доставке пакетов множеству ETR на сайтах LISP групповых получателей. Кодирование locator-set для типа EID-record может быть списком ETR, когда каждый из них регистрируется с семантикой слияния (Merge Semantics). Кодирование может быть типовым адресом локатора в кодировке AFI. При регистрации списка RTR (с несколькими уровнями в соответствии с [LISP-RE]) для кодирования локатора применяется тип Replication List Entry LCAF.

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

Multicast Info LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 9    |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Instance ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           | Source MaskLen| Group MaskLen |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |   Source/Subnet Address  ...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |       Group Address  ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Reserved

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Instance ID

Младшие 24 бита, которые могут войти в заголовок данных LISP, когда установлен бит I (см. [RFC6830]). Использование Instance ID в этом типе LCAF заключается в связывании записи групповой пересылки для данной сети VPN. Instance ID описывает VPN и регистрируется в системе сопоставления как триплет (Instance ID, S-prefix, G-prefix).

Source MaskLen

Размер маски в последующем префиксе (число установленных старших битов маски).

Group MaskLen

Размер маски в последующем групповом префиксе (число установленных старших битов маски).

AFI = x

x может быть любым значением AFI из [AFN]. Когда конкретное семейство адресов имеет семантику группового адреса, это поле должно содержать адрес группы или широковещательный адрес.

Source/Subnet Address

Адрес или префикс источника для кодирования групповой записи (S,G).

Group Address

Групповой адрес или префикс для кодирования групповых записей (S,G) или (*,G).

Это кодирование может применяться в записях EID сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании LISP-DDT [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID.

4.6. Организация трафика (TE) с повторной инкапсуляцией туннелей

При поиске данного EID в базе сопоставления может возвращаться этот формат LCAF для предоставления списка локаторов на явном пути с повторной инкапсуляцией (см. [LISP-TE]).

Explicit Locator Path (ELP) LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 10   |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Rsvd3         |L|P|S|           AFI = x             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Reencap Hop 1  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Rsvd3         |L|P|S|           AFI = x             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Reencap Hop k  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Rsvd3

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Lookup bit (L)

Бит поиска (Lookup) служащий для указания пользователю ELP не применять этот адрес при инкапсуляции, а искать его в базе сопоставлений для получения инкапсулирующего адреса RLOC.

RLOC Probe bit (P)

Это бит зонда RLOC Probe, означающий, что Reencap Hop разрешает передавать ему сообщения RLOC-probe. При сброшенном (0) бите P передавать RLOC-probe недопустимо. Когда Reencap Hop указывает anycast-адрес, несколько физических Reencap Hop используют один адрес RLOC. В этом случае RLOC-probe не нужны, поскольку при недоступности ближайшего адреса RLOC будет использован другой.

Strict bit (S)

Бит строгости (Strict), указывающий необходимость использования связанного Reencap Hop. При сброшенном (0) бите реинкапсулятор может пропустить этот Reencap и перейти к следующему в списке.

AFI = x

x может быть любым значением AFI из [AFN]. Когда AFI имеет семантику кодирования группового адреса, это поле должно содержать адрес группы или широковещательный адрес.

Это кодирование может применяться в записях RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. Это кодирование не требуется понимать системе сопоставления для поиска в базе данных, поскольку этот тип LCAF не является ключом поиска.

4.7. Сохранение данных защиты в системе сопоставления

Когда локатор в locator-set имеет связанный ключ защиты, этот тип LCAF служит для кодирования ключевого материала (см. [LISP-DDT]).

Security Key LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 11   |      Rsvd2    |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Key Count   |      Rsvd3    | Key Algorithm |   Rsvd4     |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Key Length          |       Key Material ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ... Key Material                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |       Locator Address ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Key Count

Число разделов Key (Key Length и Key Material) в LCAF.

Rsvd3

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Key Algorithm

Указывает криптографический алгоритм ключа и задаёт формат поля Public Key. Примеры использования определений для этого поля даны в [LISP-DDT] и [RFC8061].

Rsvd4

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

R bit

Бит отзыва (Revoke), установка которого указывает отзыв ключа.

Key Length

Размер поля Key Material в байтах.

Key Material

Ключевой материал, формат хранения которого зависит от поля Key Algorithm.

AFI = x

x может быть любым значением AFI из [AFN]. Это адрес локатора, владеющего закодированным ключом защиты.

Это кодирование может применяться в записях EID или RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании LISP-DDT [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID.

4.8. Поиск по парам отправитель-получатель

Когда адреса отправителя и получателя в потоке требуют рассмотрения разных locator-set, эта пара служит ключом для поска в полях EID управляющих сообщений LISP. Когда ключ Source/Dest зарегистрирован в базе сопоставлений, он будет кодироваться как префиксы отправителя и получателя. При использовании Source/Dest в качестве ключа при поиске в базе сопоставления источник и получатель берутся из пакета данных.

Source/Dest Key LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 12   |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |   Source-ML   |    Dest-ML    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |         Source-Prefix ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = y          |     Destination-Prefix ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Reserved

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Source-ML

Размер маски последующего префикса источника (число установленных старших битов маски).

Dest-ML

Размер маски последующего префикса получателя (число установленных старших битов маски).

AFI = x

x может быть любым значением AFI из [AFN].

AFI = y

y может быть любым значением AFI из [AFN]. Когда AFI имеет семантику кодирования группового адреса, это поле должно содержать адрес группы или широковещательный адрес.

Это кодирование может применяться в записях EID сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании LISP-DDT [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID. Детали применения этого типа LCAF приведены в [LISP-TE].

4.9. Записи списка репликации для групповой пересылки

Тип Replication List Entry LCAF – это кодирование локатора, который будет применяться для индивидуальной репликации в соответствии с [LISP-RE]. Это кодирование указывает тип Multicast Info LCAF и оно регистрируется маршрутизаторами RTR, участвующими в нароженном дереве распространения. Каждый маршрутизатор RTR регистрирует свой адрес RLOC и заданный в дереве растространения уровень.

Replication List Entry LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 13   |    Rsvd2      |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Rsvd3            |     Rsvd4     |  Level Value  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |           RTR/ETR #1 ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Rsvd3            |     Rsvd4     |  Level Value  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |           RTR/ETR  #n ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Rsvd3/Rsvd4

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Level Value

Значение, связанное с уровнем в иерархии дерева распространения, к которой относится RTR. Значения уровня упорядочиваются от меньших, которые ближе всего к ITR (ITR реплицируют в RTR уровня 0), к большим, расположенным ближе к ETR сайта группового получателя.

AFI = x

x может быть любым значением AFI из [AFN]. Когда AFI имеет семантику кодирования группового адреса, это поле должно содержать адрес группы или широковещательный адрес. В целях эффективности все записи RTR/ETR для одного уровня серверу Map-Server следует объединять для предотвращения поиска по всему многоуровневому списку локаторов в сообщении Map-Reply.

Это кодирование может применяться в записях RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify.

4.10. Применение типа AFI List LCAF

4.10.1. Связывание адресов IPv4 и IPv6

Когда желательна трансляция между адресами IPv4 и IPv6, можно применять канонический адрес LISP типа AFI List LCAF для передачи переменного числа AFI в одном LCAF AFI.

Address Binding LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 1    |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            AFI = 1            |       IPv4 Address ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ...  IPv4 Address         |            AFI = 2            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv6 Address ...                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ...  IPv6 Address  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ...  IPv6 Address  ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ...  IPv6 Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Этот тип формата может быть включён в Map-Request, когда адрес применяется в качестве EID, но поиск адресата в системе сопоставления LISP может использовать только адреса IPv4. Это связано с тем, что транспортная система службы сопоставления, такая как LISP-ALT [RFC6836], может применять адрес получателя Map-Request для маршрутизации управляющего сообщения на желаемый сайт LISP.

Применение. Это кодирование может применяться в записях EID или RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. Примеры использования представления в других параграфах этого раздела.

4.10.2. L2 VPN

При хранении в системе сопоставления LISP адресов MAC (Media Access Control), можно применять тип AFI List LCAF для передачи AFI 6.

MAC Address LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 1    |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             AFI = 6           |    Layer 2 MAC Address  ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ... Layer 2 MAC Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Этот формат адреса может применяться при соединении доменов L2 с использованием LISP через ядро IPv4 или IPv6 для создания L2 VPN. В этом случае MAC-адрес выступает как EID, а locator-set с которым сопоставляется EID, может быть RLOC IPv4 или IPv6 и даже MAC-адресом,применяемым как RLOC. В [EID-MOBILITY] описана работа L2 VPN при мобильности EID.

Следует принять меры защиты приватности от неправомерного использования адреса L2 MAC, обеспечив применение правил при регистрации EID, использующих кодирование с AFI=6 в записях RLOC. Дополнительные сведения представлены в документах об использовании.

4.10.3. Имена ASCII в базе сопоставлений

Если в базе сопоставления LISP хранятся имена DNS [RFC1035] или URI [RFC3986], можно применять тип AFI List LCAF для передачи строк ASCII.

ASCII LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 1    |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             AFI = 17          |      DNS Name or URI  ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Примером использования имён DNS является случай, когда ETR регистрирует сопоставления в записью EID в форме (AFI=1, 10.0.0.0/8) и записью RLOC (AFI=17, “router.abc.com”).

4.10.4. Использование рекурсивного кодирования канонических адресов LISP

Когда желательна любая комбинация перечисленного выше, значение AFI List LCAF Type может переносить внутри LCAF AFI другой LCAF AFI (например, Application-Specific Data из 5.1. Передача специфических данных приложения).

Recursive LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 1    |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 4    |     Rsvd2     |            Length2            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   IP TOS, IPv6 TC или Flow Label              |    Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Local Port (младшие биты)  |    Local Port (старшие биты)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Remote Port (младшие биты)  |   Remote Port (старшие биты)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            AFI = 1            |       IPv4 Address ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ...  IPv4 Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Length2

Размер в байтах, начиная с байта сразу после этого поля Length2.

Этот формат может применяться транспортной системой службы картографической базы данных (Mapping Database Service Transport System), такой как LISP-ALT [RFC6836], Где адрес AFI=1 IPv4 применяется как EID и помещается в адрес получателя Map-Request передающей системой LISP. Система ALT может доставить Map-Request на целевой сайт LISP независимо от значений данных Application Data LCAF Type AFI. При обработке AFI целевым сайтом LISP он будет возвращать разные наборы локаторов в зависимости от запрошенного типа приложения или уровня сервиса.

4.10.5. Пример использования режима совместимости

Система LISP может использовать формат AFI List LCAF Type при передаче системам LISP, которые не поддерживают конкретный тип LCAF, используемый для кодирования локаторов. Это даёт принимающей системе возможность разобрать адрес локатора для целей инкапсуляции. Список AFI в AFI List LCAF Type не имеет семантического упорядочения и получателю следует разбирать каждый элемент AFI независимо от их порядка.

Compatibility Mode LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 1    |     Rsvd2     |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 5    |     Rsvd2     |           Length2             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|     Latitude Degrees        |    Minutes    |    Seconds    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|     Longitude Degrees       |    Minutes    |    Seconds    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Altitude                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = 0          |           AFI = 1             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4 Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Length2

Размер в байтах, начиная с байта сразу после этого поля Length2.

Если система не распознаёт Geo-Coordinates LCAF Type, сопровождающий адрес локатора, кодировщик может включить Geo-Coordinates LCAF Type, встроенный в AFI List LCAF Type, где AFI в Geo-Coordinates LCAF Type имеет значение 0, а следующий AFI в списке кодируется с допустимым значением AFI для идентификации адреса локатора.

Для использования этой процедуры система LISP должна поддерживать AFI List LCAF Type. Пропускается более 10 байтов Geo-Coordinates LCAF Type для получения кодирования адреса локатора (адрес локатора IPv4). Система LISP, не поддерживающая Geo-Coordinates LCAF Type может поддерживать синтаксический анализ адреса локатора внутри кодировки Geo-Coordinates LCAF Type или следующее кодирование локатора в AFI List LCAF Type.

5. Экспериментальное использование канонических адресов LISP

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

5.1. Передача специфических данных приложения

Когда нужно передать набор локаторов (locator-set) на основе типа приложения или поэтапного поведения пакета (Per-Hop Behavior или PHB), можно использовать Application Data LCAF Type.

Application Data LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 4    |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       IP TOS, IPv6 TC или Flow Label          |    Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Local Port (младший номер)  |   Local Port (старший номер)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Remote Port (младший номер)  |  Remote Port (старший номер)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |         Address  ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

IP TOS, IPv6 TC, Flow Label

8-битовое поле IPv4 TOS из заголовка IPv4, 8-битовое поле IPv6 Traffic Class или Flow Label из заголовка IPv6.

Local Port/Remote Port Ranges

Это поля из транспортного заголовка TCP, UDP или SCTP5. Можно указать диапазон портов двумя значениями. При указании одного номера диапазон включает единственный порт.

AFI = x

x может быть любым значением AFI из [AFN].

Application Data LCAF Type применяется для кодирования EID, когда ITR нужен набор локаторов для конкретного приложения. При использовании для кодирования RLOC значение ETR представляет locator-set для каждого конкретного приложения, настроенного для анонсирования.

Это кодирование может применяться в записях EID или RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify. При использовании LISP-DDT [LISP-DDT] в качестве механизма системы сопоставления в сообщениях Map-Referral применяются расширенные EID. Этот тип LCAF применяется как ключ поиска в системах отображения, которые могут возвращать точное или наиболее длинное совпадение.

5.2. Базовый поиск в базе отображений

Когда LISP Mapping Database System содержит сведения, доступные по ключу с базовым (generic) форматированием (ключ не является обычным адресом IPv4 или IPv6), может быть желательным неинтерпретируемый (opaque) ключ.

Opaque Key LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 6    |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Key Field Num |      Key Wildcard Fields      |   Key . . .   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       . . . Key                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Key Field Num

Значение этого поля равно числу субполей Key за вычетом 1, поле Key может быть разделено на части. Значение 0 в этом поле говорит, что поле Key имеет одну часть. Размер субполей ключа фиксирован. Если ключ имеет размер 8 байтов, поле Key Field Num имеет значение 3, можно использовать 4 субполя по 2 байта. С учётом разумного числа разделителей субполей 16 это поле может иметь значение от 0 до 15.

Key Wildcard Fields

Указывает, какие поля ключа не применяются для поиска. Шаблон кодируется как битовое поле, бит 0 (младший) соответствует первому (младшему) полю ключа, бит 1 – второму и т. д. Установленный бит указывает, что соответствующая часть ключа не используется при поиске. Если все 16 битов шаблона имеют значение 0, для поиска применяются все биты ключа.

Key

Ключ переменного размера, для поиска в LISP Mapping Database System. Размер ключа определяет поле Length.

Это экспериментальный тип, применение которого ещё не определено.

5.3. Функциональность контроля доступа PETR

Когда общедоступное устройство PETR6 хочет узнать, кто инкапсулирует в него, он может проверить значение nonce в пакете с инкапсуляцией LISP. Для передачи nonce в ITR или PITR применяется описанный ниже тип LCAF в записи локатора Map-Register или Map-Reply.

Nonce LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 8    |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |                  Nonce                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |         Address  ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Reserved

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Nonce

Значение nonce, возвращаемое ETR в записи локатора Map-Reply для применения ITR или PITR при инкапсуляции в адрес локатора, закодированный в поле AFI этого типа LCAF. Значение nonce вставляется в поле nonce заголовка инкапсуляции LISP.

AFI = x

x может быть любым значением AFI из [AFN].

Это экспериментальный тип, применение которого ещё не определено.

5.4. Кодирование модели данных

Этот тип позволяет кодировать модель данных JSON как EID или RLOC.

JSON Data Model Type LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 14   |    Rsvd2    |B|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           JSON length         | JSON binary/text encoding ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |       Optional Address ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

B

Значение 1 указывает, что поле JSON имеет двоичное кодирование в соответствии с [JSON-BINARY], в ином случае кодирование является текстовым в соответствии с [RFC7159].

JSON length

Число октетов в следующем поле JSON binary/text encoding.

JSON binary/text encoding

Поле переменного размера в двоичном или текстовом представлении.

AFI = x

x может быть любым значением AFI из [AFN]. Конкретные AFI имеют своё кодирование индивидуального или группового адреса локатора. Все записи RTR/ETR для одного уровня следует объединять серверу Map-Server для предотвращения поиска по всему многоуровневому списку записей локаторов в сообщении Map-Reply.

Это экспериментальный тип, применение которого ещё не определено. Примером отображения является запись EID, закодированная как отличительное имя cpe-router, и запись RLOC, закодированная как строка JSON { “router-address” : “1.1.1.1”, “router-mask” : “8” }.

5.5. Кодирование адресных пар ключ-значение

Пары ключ-значение полезны, например, для присоединения атрибутов к другим элементам пакетов LISP, таким как EID или RLOC. При присоединении атрибутов к EID или RLOC требуется различать элементы, которые следует применять как EID или RLOC (следовательно, как ключи поиска и дополнительные атрибуты). Это особенно актуально в случае, когда различие невозможно провести по типам элементов, например, при использовании двух адресов IP.

Key/Value Address Pair LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 15   |     Rsvd2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |       Address as Key ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = y          |       Address as Value ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

AFI = x

x – это AFI “Address as Key”, который может иметь любое значение из [AFN]. Конкретные AFI имеют своё кодирование индивидуального или группового адреса локатора. Все записи RTR/ETR для одного уровня следует объединять серверу Map-Server для предотвращения поиска по всему многоуровневому списку записей локаторов в сообщении Map-Reply.

Address as Key

Закодированный в AFI адрес, к которому могут быть прикреплены атрибуты из следующего поля Address as Value.

AFI = y

y – это AFI “Address of Value”, который может иметь любое значение из [AFN]. [AFN]. Конкретные AFI имеют своё кодирование индивидуального или группового адреса локатора. Все записи RTR/ETR для одного уровня следует объединять серверу Map-Server для предотвращения поиска по всему многоуровневому списку записей локаторов в сообщении Map-Reply.

Address as Value

Закодированный в AFI адрес, к которому могут быть прикреплены атрибуты из предыдущего поля Address as Key.

Это экспериментальный тип, применение которого ещё не определено.

5.6. Несколько плоскостей данных

Наложения становятся все более популярными во многих частях сети, что привело к взрывному росту заголовков инкапсуляции в плоскости данных. Поскольку система отображения LISP может содержать много типов формата адресов, она может также представлять формат инкапсуляции, поддерживаемый RLOC. Когда инкапсулятор получает Map-Reply с типом Encapsulation Format LCAF в записи RLOC, он может выбрать поддерживаемый формат инкапсуляции любого протокола, для которого установлен (1) бит в этом типе LCAF.

Encapsulation LCAF

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 16   |     Rsvd2     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Reserved-for-Future-Encapsulations       |U|G|N|v|V|l|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI = x          |          Address ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length

Размер в байтах, начиная с байта сразу после этого поля Length.

Reserved-for-Future-Encapsulations

Должно устанавливаться в 0 при передаче и игнорироваться при получении. Это поле резервирует биты для будущих типов инкапсуляции.

U

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове (longword), могут воспринимать базовую инкапсуляцию UDP (Generic UDP Encapsulation или GUE) с портом назначения UDP 6080 [GUE].

G

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове, могут воспринимать инкапсуляцию Geneve с портом назначения UDP 6081 [GENEVE].

N

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове, могут воспринимать инкапсуляцию NV-GRE (Network Virtualization – Generic Routing Encapsulation), используя протокол IPv4/IPv6 номер 47 [RFC7637].

v

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове, могут воспринимать инкапсуляцию VXLAN-GPE (Generic Protocol Extension) с портом назначения UDP 4790 [GPE-VXLAN].

V

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове, могут воспринимать инкапсуляцию Virtual eXtensible Local Area Network (VXLAN) с портом назначения UDP 4789 [RFC7348].

l

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове, могут воспринимать инкапсуляцию L2 LISP с портом назначения UDP 8472 [LISP-L2].

L

RLOC, указанные в адресах с кодированием AFI в следующем длинном слове, могут воспринимать инкапсуляцию L3 LISP с портом назначения UDP 4341 [RFC6830].

Это кодирование может применяться в записях RLOC сообщений Map-Request, Map-Reply, Map-Register, Map-Notify.

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

Этот документ относится к категории экспериментальных (Experimental). Кодирование LCAF, заданное здесь, предназначено для использования в соответствующих случаях и автономных средах. Пользователям следует тщательно рассмотреть применимость модели угроз [LISP-SEC] в их варианте применения.

При использовании типа Geo-Coordinates LCAF Type могут возникать проблемы приватности и следует соблюдать осторожность при настройке системы отображения с конкретными параметрами политики, чтобы сведения о географическом положении не раздавались просто так. Для всех документов, задающих применение Geo-Coordinates LCAF рекомендуется рассмотреть применимость RFC 6280 (BCP 160) [RFC6280] для защиты приватности.

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

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

Этот документ задаёт кодирование канонического формата адреса, применяемое в управляющих сообщениях LISP и для ключей поиска в LISP Mapping Database System. Этот формат адресов основан на фиксированном AFI (16387) и поле LISP LCAF Type.

8-битовое поле LISP LCAF Type зависит от кодирования LISP Canonical Address Format. Агентство IANA создало новый реестр (в соответствии с [RFC5226]), названный LISP Canonical Address Format (LCAF) Types. Исходные значения этого реестра приведены в таблице 1. Будущие назначения будут выполняться по процедуре Specification Required [RFC5226]. Назначение включает LISP LCAF Type Name и связанное с ним значение (Таблица 1).

Таблица 1. Исходные значения реестра LISP Canonical Address Format (LCAF) Types.

 

Значение

Имя типа LISP LCAF

Ссылка

0

Null Body

Раздел 3

1

AFI List

Раздел 3

2

Instance ID

Раздел 3

3

AS Number

Раздел 3

5

Geo-Coordinates

Раздел 3

7

NAT-Traversal

Раздел 3

9

Multicast Info

Раздел 3

10

Explicit Locator Path

Раздел 3

11

Security Key

Раздел 3

12

Source/Dest Key

Раздел 3

13

Replication List Entry

Раздел 3

 

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

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

[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, “Address Allocation for Private Internets”, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3232] Reynolds, J., Ed., “Assigned Numbers: RFC 1700 is Replaced by an On-line Database”, RFC 3232, DOI 10.17487/RFC3232, January 2002, <http://www.rfc-editor.org/info/rfc3232>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, “An Architecture for Location and Location Privacy in Internet Applications”, BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, <http://www.rfc-editor.org/info/rfc6280>.

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “The Locator/ID Separation Protocol (LISP)”, RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)”, RFC 6836, DOI 10.17487/RFC6836, January 2013, <http://www.rfc-editor.org/info/rfc6836>.

[RFC7159] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, RFC 7348, DOI 10.17487/RFC7348, August 2014, <http://www.rfc-editor.org/info/rfc7348>.

[RFC7637] Garg, P., Ed. and Y. Wang, Ed., “NVGRE: Network Virtualization Using Generic Routing Encapsulation”, RFC 7637, DOI 10.17487/RFC7637, September 2015, <http://www.rfc-editor.org/info/rfc7637>.

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

[AFN] IANA, “Address Family Numbers”, <http://www.iana.org/assignments/address-family-numbers/>.

[EID-MOBILITY] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, “LISP L2/L3 EID Mobility Using a Unified Control Plane”, Work in Progress, draft-portoles-lisp-eid-mobility-01, October 2016.

[GENEVE] Gross, J., Ganga, I., and T. Sridhar, “Geneve: Generic Network Virtualization Encapsulation”, Work in Progress7, draft-ietf-nvo3-geneve-03, September 2016.

[GPE-VXLAN] Maino, F., Kreeger, L., and U. Elzur, “Generic Protocol Extension for VXLAN”, Work in Progress, draft-ietf-nvo3-vxlan-gpe-03, October 2016.

[GUE] Herbert, T., Yong, L., and O. Zia, “Generic UDP Encapsulation”, Work in Progress, draft-ietf-nvo3-gue-05, October 2016.

[JSON-BINARY] “Universal Binary JSON Specification”, <http://ubjson.org>.

[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, “LISP Delegated Database Tree”, Work in Progress8, draft-ietf-lisp-ddt-09, January 2017.

[LISP-L2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, “Layer 2 (L2) LISP Encapsulation Format”, Work in Progress, draft-smith-lisp-layer2-03, September 2013.

[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, “LISP Replication Engineering”, Work in Progress, draft-coras-lisp-re-08, November 2015.

[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, “LISP-Security (LISP-SEC)”, Work in Progress9, draft-ietf-lisp-sec-12, November 2016.

[LISP-TE] Farinacci, D., Kowal, M., and P. Lahiri, “LISP Traffic Engineering Use-Cases”, Work in Progress, draft-farinacci-lisp-te-11, September 2016.

[NAT-LISP] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, “NAT traversal for LISP”, Work in Progress, draft-ermagan-lisp-nat-traversal-11, August 2016.

[RFC8061] Farinacci, D. and B. Weis, “Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality”, RFC 8061, DOI 10.17487/RFC8061, February 2017, <http://www.rfc-editor.org/info/rfc8061>.

[WGS-84] National Imagery and Mapping Agency, “Department of Defense World Geodetic System 1984”, NIMA TR8350.2, January 2000, <http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.

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

Авторы благодарны Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann за технические и редакторские комментарии.

Спасибо Victor Moreno за обсуждения, которые привели к определению типа Multicast Info LCAF.

Спасибо Parantap Lahiri и Michael Kowalза обсуждения, которые привели к определению типа Explicit Locator Path (ELP) LCAF.

Спасибо Fabio Maino и Vina Ermaganза обсуждения, которые привели к определению типа Security Key LCAF.

Спасибо Albert Cabellos-Aparicio и Florin Corasза обсуждения, которые привели к определению типа Replication List Entry LCAF.

Спасибо Michiel Blokzijl и Alberto Rodriguez-Natal за предложение новых типов LCAF.

Спасибо Terry Manderson за помощь при получении LISP AFI от IANA.

Авторы благодарны Stephen Farrell (руководитель направления Security) и Deborah Brungard (руководитель направления Routing) за предложенный текст для прохождения документа через рецензирование IESG.

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

Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
 
Dave Meyer
Brocade
San Jose, CA
United States of America
Email: dmm@1-4-5.net
 
Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The Netherlands
Email: job@ntt.net

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Proxy Ingress Tunnel Router – маршрутизатор-посредник на входе туннеля.

4Re-encapsulating Tunnel Router – маршрутизатор, выполняющий повторную инкапсуляцию для туннеля (с удалением имеющейся).

5Stream Control Transmission Protocol – протокол управления потоковой передачей.

6Proxy Egress Tunnel Router – маршрутизатор-посредник на выходе туннеля.

7Опубликовано в RFC 8926. Прим. перев.

8Опубликовано в RFC 8111. Прим. перев.

9Опубликовано в RFC 9303. Прим. перев.

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

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