RFC 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space

Опубликовано 09.12.2012 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                          Q. Vohra
Request for Comments: 6793                              Juniper Networks
Obsoletes: 4893                                                  E. Chen
Updates: 4271                                              Cisco Systems
Category: Standards Track                                  December 2012
ISSN: 2070-1721

Поддержка 4-октетных номеров АС в протоколе BGP

BGP Support for Four-Octet Autonomous System (AS) Number Space

PDF

Аннотация

Номера автономных систем (AS1) а базовой спецификации BGP представлены 2-октетными значениями. Этот документ описывает расширение BGP для использования 4-октетных номеров AS. Документ отменяет действие RFC 4893 и обновляет RFC 4271.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

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

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

Авторские права (Copyright (c) 2012) принадлежат 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).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

В базовой спецификации BGP [RFC4271] номера AS представляются 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.

Этот документ отменяет действие RFC 4893 и обновляет RFC 4271. Он также включает некоторые разъяснения и редакторские правки, а также задает обработку ошибок для новых атрибутов.

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

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

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

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

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

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

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

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

Атрибуты AS_PATH и AGGREGATOR между новыми и старыми узлами BGP по-прежнему передаются с 2-октетными номерами AS.

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

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

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

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

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

4. Операции

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

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

Когда новый узел BGP обрабатывает сообщение OPEN от нового узла BGP, он должен использовать номер AS из поля Capability Value возможности поддержки 4-октетных номеров AS вместо значения поля My Autonomous System из сообщения OPEN.

Узел 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 — вместо этого при отсутствии у нового узла 2-октетного номера должен применяться специальный номер AS_TRANS, который может использоваться множеством AS одновременно.

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

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

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

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

Атрибут AS4_PATH (будучи необязательным переходным) будет передаваться через старые узлы BGP без изменения и поможет сохранить неотображаемые 4-октетные номера AS в информации о пути AS.

Подобно этому, если новый узел передает атрибут AGGREGATOR и агрегирующая AS имеет неотображаемый 4-октетный номер, узел должен использовать атрибут AS4_AGGREGATOR и устанавливать в поле номера AS имеющегося атрибута AGGREGATOR зарезервированное значение AS_TRANS. Отметим, что для отображаемого номера 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 документа [RFC4271] и документе [RFC5065] для выбора маршрута.

Если число номеров 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 [RFC5668] .

6. Обработка ошибок

Этот раздел обновляет RFC 4271 [RFC4271] в части обработки ошибок.

Исходя из доминирования 2-октетных номеров AS в процессе перехода и их использования в атрибуте AS_PATH старыми узлами BGP, в этом документе выбрано отбрасывание атрибутов (attribute discard) для обработки атрибутов AS4_PATH с некорректным форматом.

Поскольку атрибут AS4_AGGREGATOR является лишь информационным, для некорректно сформированных атрибутов AS4_AGGREGATOR также выбрано отбрасывание.

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

Кроме того, сегменты пути типов AS_CONFED_SEQUENCE и AS_CONFED_SET [RFC5065] недопустимо передавать в атрибуте AS4_PATH сообщения UPDATE. Новый узел BGP, получивший такой сегмент пути в атрибуте AS4_PATH сообщения UPDATE от старого узла BGP, должен отбросить эти сегменты пути, скорректировав соответствующие поля атрибутов, и продолжить обработку сообщения UPDATE. Такие случаи следует отмечать в системном журнале для анализа.

Атрибут AS4_PATH в сообщении UPDATE нужно считать сформированным некорректно при выполнении любого из перечисленных ниже условий:

  • размер атрибута не кратен 2 или слишком мал (меньше 6) для атрибута, который должен включать хотя бы один номер AS;

  • размер сегмента пути в атрибуте равен 0 или не соответствует размеру атрибута;

  • тип сегмента пути в атрибуте не относится к AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE или AS_CONFED_SET.

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

Атрибут AS4_AGGREGATOR в сообщении UPDATE нужно считать некорректно сформированным, если размер атрибута отличается от 8.

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

7. Переход

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

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

В среде, где AS со старыми узлами BGP имеет партнерские отношения с двумя или более AS, включающими новые узлы BGP, и использует AS_TRANS (а не уникальный в глобальном масштабе отображаемый номер AS), использование атрибута MULTI_EXIT_DISC [RFC4271] автономной системой со старыми узлами BGP может приводить к ситуации, когда атрибут MULTI_EXIT_DISC будет влиять на выбор среди маршрутов, полученных из других соседних AS.

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

8. Вопросы управляемости

Если поддерживается BGP4-MIB [RFC4273], не возникает дополнительный вопросов управляемости в результате использования 4-октетных номеров AS, поскольку текстовое соглашение InetAutonomousSystemNumber [RFC4001] определено как Unsigned32.

При поддержке IPFIX5 [RFC5101] не возникает дополнительный вопросов управляемости в результате использования 4-октетных номеров AS. Информационные элементы bgpSourceAsNumber и bgpDestinationAsNumber [IANA-IPFIX] могут по-прежнему применяться, поскольку в новом шаблоне для них задан размер 4 октета.

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

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

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

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

Этот документ заменяет ссылку на RFC 4893 ссылкой на данный документ в части резервирования 2-октетного номера AS_TRANS (23456). Агентство IANA заменило ссылку на RFC 4893 ссылкой на данный документ в реестре 32-bit Autonomous System Numbers.

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

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

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

Будет конфигурационной ошибкой назначение неотображаемых 4-октетных номеров AS в качестве Member AS Number в BGP Confederation до того, как все узлы BGP в конфедерации начнут поддерживать 4-октетные номера AS. Такие конфигурационные ошибки ослабляют возможности обнаружения петель в путях AS внутри конфедерации.

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

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

Авторы также благодарны участникам рабочей группы IDR за их рецензии и комментарии.

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

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

[RFC1997] Chandra, R., Traina, P., and T. Li, “BGP Communities Attribute”, RFC 1997, August 1996.

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

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, January 2006.

[RFC5065] Traina, P., McPherson, D., and J. Scudder, “Autonomous System Confederations for BGP”, RFC 5065, August 2007.

[RFC5492] Scudder, J. and R. Chandra, “Capabilities Advertisement with BGP-4”, RFC 5492, February 2009.

[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, “4-Octet AS Specific BGP Extended Community”, RFC 5668, October 2009.

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

[IANA-IPFIX] IANA, “IP Flow Information Export (IPFIX) Entities”, <http://www.iana.org/assignments/ipfix>.

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, “Textual Conventions for Internet Network Addresses”, RFC 4001, February 2005.

[RFC4273] Haas, J., Ed., and S. Hares, Ed., “Definitions of Managed Objects for BGP-4”, RFC 4273, January 2006.

[RFC5101] Claise, B., Ed., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information”, RFC 5101, January 2008.

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

Quaizar Vohra

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

USA

EMail: quaizar.vohra@gmail.com

Enke Chen

Cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

USA

EMail: enkechen@cisco.com



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


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


nmalykh@gmail.com 




1Autonomous System.






2Internet Engineering Task Force.






3Internet Engineering Steering Group.






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






5IP Flow Information Export — экспорт информации о потоках IP.



 											


		
						

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