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
Статус документа
В этом документе содержится проект стандарта 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
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The IETF Trust (2007).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.
1Autonomous System — автономная система.
4Работа опубликована в RFC 5668. Прим. перев.
