RFC 4893 BGP Support for Four-octet AS Number Space

Please enter banners and links.

image_print
Network Working Group                                       Q. Vohra
Request for Comments: 4893                          Juniper Networks
Category: Standards Track                                    E. Chen
                                                       Cisco Systems
                                                            May 2007

 

 

Поддержка 4-октетных номеров AS в BGP

BGP Support for Four-octet AS Number Space

PDF

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

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

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

Copyright (C) The IETF Trust (2007).

Тезисы

В настоящее время автономные системы (AS1) в протоколе BGP представляются 2-октетными значениями. В этом документе рассматривается расширение протокола BGP, позволяющее использовать четырехоктетные номера AS.

1. Введение

В настоящее время автономные системы (AS) в протоколе BGP [BGP] представляются 2-октетными значениями. Для решения проблемы нехватки двухоктетных номеров AS в этом документе предлагается расширение протокола BGP, позволяющее использовать 4-октетные номера AS.

Говоря точнее, этот документ определяет новую возможность протокола BGP — Four-octet AS Number Capability, которая может использоваться узлом BGP для индикации поддержки этим узлом четырехоктетных номеров AS. Для реализации новой возможности добавляются два новых атрибута AS4_PATH и AS4_AGGREGATOR, которые могут использоваться для распространения 4-октетных номеров AS в атрибутах пути между узлами BGP, которые не поддерживают этого расширения. В документе также предложен механизм представления информации о путях с использованием атрибутов AS_PATH и AS4_PATH.

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

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

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

3. Расширение протокола

В этом документе узлы BGP, не поддерживающие 4-октетные номера AS, будет называться старыми узлами BGP, а поддерживающие расширение узлы — новыми узлами BGP.

BGP передает номера автономных систем в поле My Autonomous System сообщений OPEN, а также в атрибутах AS_PATH и AGGREGATOR сообщений UPDATE. Кроме того, номера автономных систем BGP включаются в атрибуты BGP Communities.

Новые узлы BGP используют BGP Capability Advertisement [RFC2842] для анонсирования своим соседям (внутренним или внешним) поддержки 4-октетных номеров AS, описанной в данном документе.

Возможность (Capability), используемая узлом BGP для передачи другим узлам BGP информации о поддержке 4-октетных номеров AS, также использует передачу 4-октетного номера AS данного узла в поле Capability Value дополнительного параметра (Capability Optional Parameter). Поле Capability Length для Capability имеет значение 4.

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

Для передачи информации о пути через старые узлы BGP в данном документе определен новый атрибута пути — AS4_PATH. Этот дополнительный переходный атрибут содержит значение AS path, представленное 4-октетными номерами AS. Атрибут AS4_PATH семантически не отличается от атрибута AS_PATH, но относится к числу дополнительных переходных атрибутов и использует 4-октетные номера AS.

Для предотвращения возможности распространения внутренних сегментов путей конфедераций за пределы этих конфедераций, типы сегментов пути AS_CONFED_SEQUENCE и AS_CONFED_SET [RFC3065] для атрибута AS4_PATH считаются некорректными.

Для выполняющих агрегирование новых узлов BGP в документе определен дополнительный переходный атрибут AS4_AGGREGATOR. Семантика атрибутов AS4_AGGREGATOR и AGGREGATOR одинакова, но первый использует 4-октетный номер AS.

Выделенные к настоящему времени 2-октетные номера AS преобразуются в 4-октетные номера AS путем установки в 0 двух старших октетов номера. Такие 4-октетные номера AS могут быть отображены на 2-октетные номера AS.

Для представления 4-октетных номеров AS с отличными от 0 старшими октетами (такие номера не отображаются на 2-октетные) в информации AS path, содержащей 2-октетные номера AS, в настоящем документе резервируется специальный 2-октетный номер AS. Этот специальный номер AS в остальной части спецификации будет обозначаться AS_TRANS. Этот номер также включается в поле “My Autonomous System” сообщений OPEN, инициируемых новым узлом BGP, если последний не имеет уникального в глобальном масштабе 2-октетного номера AS.

4. Операции

4.1. Взаимодействие между новыми узлами BGP

Узлам BGP, поддерживающим 4-октетные номера AS, следует анонсировать эту возможность с использованием BGP Capability Advertisement. Узел BGP, который анонсировал тому или иному партнеру такую возможность и получил от партнера аналогичный анонс, должен использовать 4-октетные номера AS в атрибутах AS_PATH и AGGREGATOR обновлений, передаваемых этому партнеру, а в принятых от того обновлениях должен рассматривать эти атрибуты, как содержащие 4-октетные номера AS.

Новые атрибуты AS4_PATH и AS4_AGGREGATOR не следует передавать в сообщениях UPDATE между новыми узлами BGP. Новому узлу BGP, получившему атрибуты AS4_PATH или AS4_AGGREGATOR в сообщении UPDATE от нового узла BGP, следует отбросить эти атрибуты и продолжить обработку сообщения UPDATE.

4.2. Взаимодействие между новыми и старыми узлами BGP

4.2.1. Партнерство BGP

Отметим, что партнерские отношения между новым и старым узлами BGP возможны только в том случае, когда новый узел BGP имеет 2-октетный номер AS. Однако в этом документе не предполагается, что каждому новому узлу BGP требуется выделить уникальный 2-октетный номер AS — вместо этого предлагается специальный номер AS_TRANS, который может использоваться множеством AS.

4.2.2. Генерация обновлений

При взаимодействии со старыми узлами BGP новый узел должен передавать информацию о пути в атрибутах AS_PATH с 2-октетными номерами AS. Новый узел должен также передавать информацию о пути в атрибутах AS4_PATH (с 4-октетными номерами AS) за исключением тех случаев, когда вся информация о пути представлена 2-октетными номерами AS. В последнем случае новому узлу BGP не следует передавать атрибут AS4_PATH.

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

Новый узел BGP создает атрибут AS4_PATH из информации, содержащейся в атрибуте AS_PATH. В случаях, когда атрибут AS_PATH содержит сегменты пути AS_CONFED_SEQUENCE или AS_CONFED_SET, новый узел BGP при создании атрибута AS4_PATH из AS_PATH должен исключить такие сегменты пути. Атрибут AS4_PATH будет передаваться через старые узлы BGP без изменения и поможет корректно восстановить 4-октетные номера AS в информации о пути.

Подобно этому, если новый узел передает атрибут AGGREGATOR и агрегирующая система имеет 4-октетный номер, узел создает AS4_AGGREGATOR, беря размер и значение атрибута AGGREGATOR, помещает их в атрибут AS4_AGGREGATOR и устанавливает в поле номера AS атрибута AGGREGATOR зарезервированное значение AS_TRANS. Отметим, что для 2-октетного номера AS использовать атрибут AS4_AGGREGATOR не следует.

4.2.3. Обработка полученных обновлений

Когда новый узел BGP получает обновление от старого узла, ему следует быть готовым к обработке атрибутов AS4_PATH, наряду с AS_PATH. При наличии AS4_PATH оба атрибута будут использоваться для восстановления точной информации о пути и, следовательно, информация из обоих типов атрибутов будет приниматься во внимание при определении петель.

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

При некоторых условиях восстановление полной информации о пути из атрибутов AS_PATH и AS4_PATH может оказаться невозможным. Это происходит в тех случаях, когда два или более маршрута, содержащие атрибут AS4_PATH, агрегируются старым узлом BGP, а атрибут AS4_PATH по крайней мере одного из таких маршрутов содержит по крайней мере один 4-октетный номер AS (в противоположность 2-октетному номеру AS, представленному 4 октетами). В зависимости от реализации при агрегировании может быть потерян атрибут AS4_PATH или оба атрибута AS_PATH и AS4_PATH будут содержать корректную частичную информацию, которая не может быть объединена без разрывов, приводящих к неполноте информации о пути.

Новому узлу BGP следует также быть готовым к получению от старого узла BGP атрибута AS4_AGGREGATOR вместе с атрибутом AGGREGATOR. При получении обоих атрибутов, если номер AS в атрибуте AGGREGATOR не совпадает с AS_TRANS:

  • атрибуты AS4_AGGREGATOR и AS4_PATH следует игнорировать;

  • атрибут AGGREGATOR следует трактовать как информацию об агрегирующем узле;

  • атрибут AS_PATH следует трактовать как информацию о пути.

В остальных случаях:

  • атрибут AGGREGATOR следует игнорировать;

  • атрибут AS4_AGGREGATOR следует трактовать как информацию об агрегирующем узле;

  • информацию о пути следует конструировать как во всех остальных случаях.

Для конструирования информации о пути необходимо сначала рассчитать номера AS в атрибутах AS_PATH и AS4_PATH с использованием метода, описанного в параграфе 9.1.2.2 документа [BGP] и документе [RFC3065] для выбора маршрута.

Если число номеров AS в атрибуте AS_PATH меньше числа номеров AS в AS4_PATH, атрибут AS4_PATH следует игнорировать, а атрибут AS_PATH следует трактовать как информацию о пути.

Если число номеров AS в атрибуте AS_PATH больше или равно числу номеров AS в AS4_PATH, информацию о пути следует восстанавливать, принимая столько номеров AS и сегментов пути из атрибута AS_PATH, сколько требуется и добавляя их в начало (prepend) атрибута AS4_PATH так, чтобы в результате число номеров AS в информации о пути совпадало с числом номеров AS в атрибуте AS_PATH. Отметим, что перед корректными сегментами пути AS_CONFED_SEQUENCE или AS_CONFED_SET следует добавлять (prepend) информацию, если сегмент является первым в пути или смежным с сегментом, перед которым добавляется информация.

5. Обслуживание групп BGP

Как отмечено в [RFC1997], два старших октета атрибута группы (community attribute) не могут принимать значения 0x0000 или 0xffff, в этих двух октетах указывается номер AS. Понятно, что это условие не будет работать для узлов BGP, которые используют 4-октетные номера AS. Таким узлам BGP следует использовать специальное расширение Four-octet AS Specific Extended Communities [AS-EXT-COM] .

6. Переход

Описанная в этом документе схема обеспечивает возможность постепенного перехода от 2-октетных номеров AS к 4-октетным номерам. Каждая AS или узел BGP могут переходить к 4-октетным номерам независимо.

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

Старым узлам BGP недопустимо использовать значение AS_TRANS в качестве своего номера AS.

Неотображаемый 4-октетный номер AS не может использоваться как “Member AS Number” в конфедерации BGP, пока все узлы BGP в масштабе этой конфедерации не будут готовы к поддержке 4-октетных номеров AS.

В среде, где автономная система со старыми узлами BGP имеет партнерские отношения по крайней мере с двумя автономными системами, где имеются новые узлы BGP и используется значение AS_TRANS (взамен уникального номера AS), применение атрибутов Multi-Exit Discriminator автономной системой со старыми узлами может приводить к возникновению ситуаций, когда атрибут MED будет влиять на выбор маршрута среди маршрутов, полученных из разных соседних AS.

В некоторых условиях реконструирование полной информации о пути из атрибутов AS_PATH и AS4_PATH может оказаться невозможным. Это происходит в тех случаях, когда по крайней мере два маршрута, передающих атрибут AS4_PATH, агрегируются старым узлом BGP и атрибут AS4_PATH по крайней мере одного из таких маршрутов содержит хотя бы один 4-октетный номер AS (в противоположность 2-октетным номерам, представленным 4 октетами). Когда такое агрегирование приводит к созданию маршрута, являющегося менее специфичным, чем любая из компонент агрегирования (значение NLRI агрегированного маршрута покрывает NLRI всех компонент), потеря информации о пути не создает риска возникновения петли. В остальных случаях потеря информации о пути может приводить к возникновению петли.

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

Этот документ расширяет пространство номеров AS с 0 – 65535 до 0 – 4294967295. Распределение номеров AS фиксируется в реестре IANA Autonomous System Numbers. Кроме расширения пространства номеров AS в данном документе не предлагается каких-либо изменений существующих правил и процедур распределения номеров AS.

Этот документ использует код BGP Capability для индикации поддержки узлом BGP 4-октетных номеров AS. Выделенное IANA в соответствии с RFC 2842 значение кода равно 65.

Кроме того, в этом документе определены два новых дополнительных переходных атрибута BGP, коды которых согласуются с IANA. Для атрибута AS4_PATH выделено значение 17, которое используется для передачи информации AS path с 4-октетными номерами AS через старые системы BGP. Для второго атрибута AS4_AGGREGATOR выделено значение 18. Этот атрибут используется подобно AGGREGATOR, но содержит 4-октетный номер AS.

В этом документе резервируется также 2-октетный номер AS — AS_TRANS. Для AS_TRANS агентством IANA выделено значение 23456.

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

Расширение BGP не меняет состояния безопасности существующего протокола BGP за исключением указанного ниже.

Несогласованность атрибутов AS_PATH и AS4_PATH может приводить к возникновению петель в информации AS path и, потенциально, в маршрутах, как отмечено выше. Эта особенность может быть использована для организации атак.

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

Авторы благодарят Yakov Rekhter, Chaitanya Kodeboyina и Jeffrey Haas за плодотворные дискуссии при подготовке документа.

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

[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “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.

[RFC3392] Chandra, R. and J. Scudder, “Capabilities Advertisement with BGP-4”, RFC 33922, November 2002.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, “Autonomous System Confederations for BGP”, RFC 30653, February 2001.

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

11. Дополнительные ссылки

[AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, “Four-octet AS Specific BGP Extended Community”, Work in Progress4, April 2007.

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

Quaizar Vohra

Juniper Networks

1194 N.Mathilda Ave

Sunnyvale, CA 94089

EMail: quaizar.vohra@gmail.com

Enke Chen

Cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: enkechen@cisco.com

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

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

nmalykh@protocols.ru

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

Copyright (C) The IETF Trust (2007).

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, THE IETF TRUST 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 в настоящее время обеспечивается Internet Society.

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

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

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

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

 

Сохранить

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

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

Or