Internet Engineering Task Force (IETF) A. Rodriguez-Natal
Request for Comments: 9306 Cisco
Updates: 8060 V. Ermagan
Category: Experimental Google, Inc.
ISSN: 2070-1721 A. Smirnov
V. Ashtaputre
Cisco
D. Farinacci
lispers.net
October 2022
Vendor-Specific LISP Canonical Address Format (LCAF)
Фирменные LCAF
Аннотация
Этот документ описывает новый формат канонического представления адресов (Canonical Address Format или LCAF) протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP) для фирменных (Vendor-Specific) LCAF. Этот формат позволяет организациям применять своё кодирование LCAF. Документ обновляет RFC 8060.
Статус документа
Этот документ не является спецификацией Track и публикуется для проверки, экспериментальной реализации и оценки.
Документ определяет экспериментальный протокол для сообщества Internet. Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9306.
Авторские права
Copyright (c) 2022. Авторские права принадлежат 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 (LCAF) [RFC8060] задаёт форму и представление адресов разных типов, которые могут применяться в реализациях протокола LISP [RFC9300] [RFC9301]. Однако в некоторых реализациях могут применяться особые форматы, не применимые в других реализациях. Этот документ расширяет [RFC8060], вводя фирменный формат (Vendor-Specific LCAF), определяющий способ создания адресов LCAF для использования в конкретных реализациях LISP. Этот документ также обновляет [RFC8060], задавая поведение для нераспознанных типов LCAF.
2. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
3. Нераспознанные типы LCAF
В [RFC8060] обработка неизвестных типов LCAF не описана. Этот документ обновляет [RFC8060], указывая, что любые нераспознанные типы LCAF, полученные в сообщении плоскости управления LISP, должны игнорироваться. Если игнорируются все локаторы, это эквивалентно приёму управляющего сообщения LISP с Locator Count = 0, как указано в [RFC9301]. Если EID-Prefix содержит лишь нераспознанные типы LCAF, управляющее сообщение LISP должно отбрасываться, а в системный журнал должна вноситься запись об этом (EID обозначает идентификатор конечной точки).
4. Фирменные LCAF
В Vendor-Specific LCAF используется уникальный идентификатор организации (IEEE Organizationally Unique Identifier или OUI) [IEEE.802] для предотвращения конфликтор при использовании LCAF. Формат Vendor-Specific LCAF показан на рисунке 1.
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 = 255 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Organizationally Unique Identifier (OUI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internal format... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 1. Фирменный LCAF.
Поля первых 8 октетов Vendor-Specific LCAF совпадают с полями базового формата LCAF, заданного в [RFC8060]. Поле Type должно иметь значение 255, выделенное IANA для фиременныхLCAF (см. 6. Взаимодействие с IANA). Значение поля Length учитывает поле Internal format, а также поля OUI и Rsvd3 как в [RFC8060]. Эти поля для Vendor-Specific LCAF описаны ниже.
Rsvd3
8-битовое резервное поле. Оно должно иметь значение 0 при передаче, а получатель должен игнорировать поле.Organizationally Unique Identifier (OUI)
24-битовое поле OUI или идентификатора компании (Company ID или CID), выделенного агентством регистрации IEEE (Registration Authority или RA) в соответствии со стандартом IEEE Std 802 [IEEE.802]Internal format
Поле переменного размера, не задаваемое этим документом. Каждый производитель или организация могут задавать свои форматы для использования в Vendor-Specific LCAF.Тип Vendor-Specific LCAF не следует применять в системах, где взаимодействуют разные организации. Однако во многих случаях на практике две или более организации используют общую систему и тогда им требуется явно согласовать применение конкретных Vendor-Specific LCAF. В таких случаях вовлечённые организации должны тщательно оценить взаимодействия в конкретном развёртывании. Не рекомендуется применять значения OUI, не выделенные организации.
Если устройство LISP получает сообщение LISP, содержащее Vendor-Specific LCAF с неизвестным OUI, оно должно отбросить это сообщение и следует указать это событие в системном журнале.
5. Вопросы безопасности
Этот документ позволяет организациям определять новые LCAF для внутреннего использования. Организации сами отвечают за оценку влияния этих форматов на безопасность. Соображения безопасности, приведённые в [RFC8060], применимы и к этому документу.
6. Взаимодействие с IANA
В соответствии с рекомендациями [RFC8126] агентство IANA выделило для Vendor-Specific LCAF значение из реестра LISP Canonical Address Format (LCAF) Types, заданного в [RFC8060]).
Таблица 1. Назначение Vendor-Specific LCAF.
|
Значение |
Имя типа LISP LCAF |
Документ |
|---|---|---|
|
255 |
Vendor Specific |
RFC 9306, раздел 4 |
7. Нормативные документы
[IEEE.802] IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture”, DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802, July 2014, <https://ieeexplore.ieee.org/document/6847097>.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, “LISP Canonical Address Format (LCAF)”, RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.
Благодарности
Авторы признательны Joel Halpern, Luigi Iannone, Alvaro Retana за предложения и рекомендации.
Адреса авторов
Alberto Rodriguez-Natal Cisco Spain Email: natal@cisco.com Vina Ermagan Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: ermagan@gmail.com Anton Smirnov Cisco Diegem Belgium Email: asmirnov@cisco.com Vrushali Ashtaputre Cisco San Jose, CA United States of America Email: vrushali@cisco.com Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.comПеревод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.