Перевод RFC 3065

На главную

Network Working Group Request for Comments: 3065 Obsoletes: 1965 Category: Standards Track

P. Traina

Juniper Networks, Inc.

D. McPherson

Amber Networks, Inc.

J. Scudder

Cisco Systems, Inc.

February 2001

Конфедерации автономных систем в BGP

Autonomous System Confederations for BGP

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

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

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

Тезисы

Протокол BGP¹ представляет собой протокол маршрутизации между автономными системами, разработанный для сетей TCP/IP². BGP требует, чтобы все узлы BGP в одной автономной системе (AS) были связаны между собой (fully meshed - “каждый с каждым”). Это требование порождает серьезные проблемы масштабирования, отмеченные в многочисленных документах.

Данный документ описывает расширение BGP, которое может использоваться для создания конфедерации автономных систем, представляющихся как единая АС для узлов BGP, не входящих в конфедерацию. Это позволяет решить проблему “полносвязности”. Смысл этого расширения состоит в расширении возможностей управления политикой и упрощения поддержки больших автономных систем.

1. Спецификация требований

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

2. Введение

В соответствии со спецификацией протокол BGP требует, чтобы каждый узел BGP в одной AS имел соединения со всеми другими узлами BGP в этой автономной системе (fully meshed). Результатом этого является необходимость поддержки каждым узлом BGP (в автономной системе с числом узлов n) n*(n-1)/2 уникальных сессий IBGP. Это требование “полносвязности” создает проблемы масштабирования для АС с большим числом узлов IBGP, обычным для многих современных сетей.

Эта проблема масштабирования описана во множестве документов и существует целый ряд предложений по ослаблению проблемы [3,5]. В этом документе предлагается дополнительный способ ослабления проблемы полносвязности, известный как "Autonomous System Confederations for BGP³" или просто "BGP Confederations⁴". Можно также сказать, что конфедерации BGP могут повышать эффективность управления политикой маршрутизации.

Этот документ является пересмотром RFC 1965 [4] и включает редакторские правки, разъяснения и корректировки, основанные на опыте развертывания BGP Confederations. Изменения по сравнению с упомянутым документом перечислены в Приложении A.

3. Термины и определения

AS Confederation

Группа автономных систем, анонсируемых с общим номером AS узлам BGP, не входящим в данную конфедерацию.

AS Confederation Identifier

Видимый снаружи номер автономной системы, идентифицирующий конфедерацию в целом.

¹Border Gateway Protocol

²Transmission Control Protocol/Internet Protocol

³Конфедерации автономных систем для BGP

⁴BGP-конфедерации

rfc.com.ru

Перевод RFC 3065

Member-AS

Автономная система, включенная в данную конфедерацию AS.

Member-AS Number

Номер автономной системы, видимый только членам данной конфедерации BGP.

4. Обсуждение

Может оказаться полезным деление автономных систем с большим числом узлов BGP на более мелкие домены в целях управления политикой маршрутизации с помощью данных, содержащихся в атрибуте BGP AS_PATH. Например, можно рассматривать все узлы BGP в неком географическом регионе как единый объект. Кроме потенциального повышения уровня контроля за политикой маршрутизации (если не используются методы типа описанного здесь или в документе [5]) спецификация протокола [1] требует, чтобы все узлы BGP одной автономной системы организовали полносвязную (full mesh) систему соединений TCP со всеми другими узлами для обмена внешней маршрутной информацией. В автономных системах число внутридоменных соединений, которые должен поддерживать каждый граничный маршрутизатор, может становиться весьма значительным.

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

К сожалению деление автономной системы на части может увеличить сложность реализации политики маршрутизации на основе данных из атрибутов AS_PATH для всех членов Internet. Кроме того, это деление увеличит издержки на управление и координацию внешних партнерских связей при изменении внутренней топологии этого множества автономных систем.

И, наконец, деление больших AS может привести к неоправданному увеличению размера упорядоченной части атрибута AS_PATH. Некоторые распространенные реализации BGP могут использовать число “интервалов между AS” (AS hops) до данного адресата, как часть критерия выбора пути. Хотя такой метод определения предпочтительного маршрута не является оптимальным, при нехватке других данных он обеспечивает разумное поведение “по умолчанию”, широко используемое в сети Internet. Следовательно, деление автономной системы на отдельные фрагменты может оказать существенное влияние на уровень оптимальности маршрутизации пакетов через Internet.

Однако обычно не возникает необходимости в раскрытии внутренней топологии таких поделенных на части автономных систем и это означает, что возможно представление множества автономных систем с единым администрированием как единого объекта или AS с точки зрения находящихся за пределами данной конфедерации автономных систем.

5. Расширение AS_CONFED для типа сегмента

В действующей спецификации BGP сказано, что атрибут AS_PATH является хорошо известным обязательным атрибутом, состоящим из последовательности сегментов пути (AS path segment). Каждый сегмент пути представляется триплетом <path segment type, path segment length, path segment value>.

В соответствии с [1] тип сегмента пути задается однооктетным полем, для которого определены следующие значения:

Значение Имя Описание

1 AS_SET Неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

2 AS_SEQUENCE Упорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE. В настоящем документе определены два дополнительных типа сегментов пути:

Значение Имя Описание

AS_CONFED_SEQUENCE Упорядоченный набор номеров Member AS в локальной конфедерации, через которую

3 передается сообщение UPDATE.

AS_CONFED_SET Неупорядоченный набор номеров Member AS в локальной конфедерации, через

4 которую передается сообщение UPDATE.

6. Принцип работы

Член конфедерации BGP будет использовать свое значение AS Confederation ID во всех транзакциях с партнерами, которые не являются членами данной конфедерации. Этот идентификатор конфедерации рассматривается как видимый извне номер AS, этот номер используется в сообщениях OPEN и анонсируется в атрибуте AS_PATH.

Член конфедерации BGP будет использовать свое значение Member AS Number во всех транзакциях с партнерами, входящими в данную конфедерацию.

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

Узлу BGP, получившему атрибут AS_PATH с сегментами AS_CONFED_SEQUENCE или AS_CONFED_SET, содержащими его Member AS Number, следует трактовать путь так же, как это делается для путей, содержащих номер AS этого узла.

6.1. Правила изменения AS_PATH

Параграф 5.1.2 документа [1] заменяется приведенным ниже текстом:

Когда узел BGP распространяет маршрут, который был получен в сообщении UPDATE от другого узла BGP, ему следует изменить атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

a) Когда данный узел BGP анонсирует маршрут другому узлу BGP, расположенному в той же автономной системе, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH.

b) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, анонсирующему узлу следует изменить связанный с этим маршрутом атрибут AS_PATH как показано ниже:

rfc.com.ru 2 rfc.com.ru

Перевод RFC 3065

1) если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, локальной системе следует поместить свой номер AS как последний элемент списка (в крайнюю левую позицию).

2) если первый сегмент AS_PATH имеет тип, отличный от AS_CONFED_SEQUENCE, локальной системе следует поместить новый сегмент типа AS_CONFED_SEQUENCE в путь AS_PATH, включив свой идентификатор конфедерации в этот сегмент.

c) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе и не являющемуся членом конфедерации (в которую входит данный узел), анонсирующему узлу следует изменить атрибут AS_PATH как показано ниже:

1) если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, данный сегмент и все непосредственно следующие за ним сегменты типа AS_CONFED_SET или AS_CONFED_SEQUENCE удаляются из атрибута AS_PATH и после этого для атрибута выполняется этап 2 или 3 (см. ниже).

2) Если первый оставшийся сегмент AS_PATH имеет тип AS_SEQUENCE, локальной системе следует поместить свой идентификатор конфедерации в качестве последнего элемента (поместить идентификатор в крайнюю левую позицию).

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

Когда узел BGP является источником маршрута, этому узлу следует:

a) включать пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в Member AS Number (пустой атрибут AS_PATH содержит нулевое значение в поле размера);

b) включать свой Member AS Number в сегмент AS_CONFED_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, являющихся членами конфедерации (т. е., значение Member AS Number исходного отправителя будет единственным элементом атрибута AS_PATH);

c) включать номер AS своей конфедерации в сегмент AS_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, которые не являются членами данной конфедерации; в этом случае номер AS конфедерации будет единственным элементом атрибута AS_PATH.

7. Общие вопросы администрирования

Вполне разумно в рамках конфедерации использовать единое администрирование и информацию IGP.

Узлам BGP следует разрешить анонсирование неизмененных атрибутов NEXT_HOP и MULTI_EXIT_DISCRIMINATOR (MED) партнерам из соседних AS, входящих в ту же конфедерацию. В дополнение к этому отменяется ограничение на передачу атрибута LOCAL_PREFERENCE партнерам из соседних AS своей конфедерации. Критерии выбора пути для информации, полученной от членов конфедерации должны быть такими же, какие указаны для партнеров из своей автономной системы в спецификации [1].

8. Вопросы совместимости

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

Любой узел BGP, не поддерживающий эти расширения, будет генерировать сообщение NOTIFICATION с кодом ошибки "UPDATE Message Error" и субкодом "Malformed AS_PATH".

Перечисленные выше проблемы совместимости требуют от всех включаемых в конфедерацию узлов BGP поддержки данного расширения (BGP confederations). Однако от узлов BGP за пределами конфедерации такой поддержки не требуется.

9. Развертывание конфедераций

Конфедерации BGP широко распространены в сети Internet уже много лет и поддерживаются множеством производителей.

Некорректная настройка конфедерации BGP может приводить к ненужному дублированию маршрутной информации внутри AS. Такое дублирование будет отнимать системные ресурсы, приводить к ненужным переключениям маршрутов (flap) и увеличивать задержку схождения (convergence).

Следует принять меры по фильтрации вручную дубликатов анонсов, вызванных прохождением информации о доступности через множество включенных в конфедерацию автономных систем, что обусловлено топологией конфедерации и требованиями по резервированию соединений.

В дополнение к этому конфедерации (как и рефлекторы маршрутов), исключая из рассмотрения информацию о доступности в различных точках конфедерации, могут вызывать постоянные осцилляции между маршрутами-кандидатами при использовании правил “развязывания узлов” (tie breaking), требуемых спецификацией BGP [1]. Следует с осторожностью относиться к выбору значений MED и правилам tie breaking для предотвращения проблем.

Одним из способов предотвращения проблем является установка для метрики inter-Member-AS IGP⁵ значения большего, нежели для метрики intra-Member-AS IGP⁶, и/или использование иных правил tie breaking для предотвращения выбора маршрутов BGP на основе несравнимых MED.

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

Это расширение не оказывает влияния на проблем безопасности протокола BGP, рассмотренные в документе [6].

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

Общая концепция конфедераций BGP была заимствована из Routing Domain Confederations для IDRP [2]. Часть вводного текста этого документа была заимствована из [5].

⁵Протокол внутренней маршрутизации между членами конфедерации. ⁶Протокол внутренней маршрутизации для входящих в конфедерацию AS.

rfc.com.ru 3 rfc.com.ru

Перевод RFC 3065

Авторы выражают свою признательность Bruce Cole из Juniper Networks за его информацию о реализации и анализ ограничений расширения протокола, описанного в данном документе и работе [5]. Мы также благодарим Srihari Ramachandra из Cisco Systems, Inc. За его отклики.

Авторы также выражают свою признательность Ravi Chandra и Yakov Rekhter за конструктивные и полезные замечания в процессе работы с ранними версиями этого документа.

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

[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771⁷, March 1995.

[2] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC 10747, October 1993.

[3] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh routing", RFC 1863, October 1995.

[4] Traina, P. "Autonomous System Confederations for BGP", RFC 1965, June 1996.

[5] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection An Alternative to Full Mesh IBGP", RFC 2796, April 2000.

[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385⁸, August 1998.

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

Paul Traina

Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA Phone: +1 408 745-2000 EMail: pst+confed@juniper.net

Danny McPherson

Amber Networks, Inc.

48664 Milmont Drive

Fremont, CA 94538

Phone: +1 510.687.5226

EMail: danny@ambernetworks.com

John G. Scudder

Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 734.669.8800 EMail: jgs@cisco.com

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

nmalykh@bilim.com

Приложение A: Сравнение с RFC 1965

Наиболее важным отличием от [4]⁹ является замена значений AS_CONFED_SEQUENCE(4) и AS_CONFED_SET(3) на значения, определенные в параграфе "Расширение AS_CONFED для типа сегмента". Причина этой замены обусловлена тем, что в начальных реализациях, которые достаточно широко распространены, были использованы значения, поменянные местами по сравнению с [4] и такое использование продолжалось в последующих реализациях. Для обеспечения интероперабельности и совместимости с имеющимися реализациями значения в данном документе были поменяны местами.

Параграф "Обсуждение совместимости¹⁰" был исключен, а вопросы из этого параграфа рассмотрены в других частях данного документа. Были также исключены упоминания иерархических конфедераций. Термин "Routing Domain Identifier" был заменен термином “Member AS Number”.

Наконец, был расширен параграф "Развертывание конфедераций" и в него были внесены некоторые грамматические изменения.

⁷Этот вариант спецификации протокола признан устаревшим и заменен RFC 4271. Перевод имеется на сайте

http://rfc.com.ru. Прим. перев.

⁸Перевод этого документа доступен на сайте http://rfc.com.ru. Прим. перев.

⁹В оригинале эта ссылка ошибочно указывает на документ [1]. Прим. перев.

¹⁰Compatibility Discussion

rfc.com.ru 4 rfc.com.ru


	На главную




	Network Working Group Request for Comments: 3065 Obsoletes: 1965 Category: Standards Track			P. Traina Juniper Networks, Inc. D. McPherson Amber Networks, Inc.
				J. Scudder Cisco Systems, Inc. February 2001

	Конфедерации автономных систем в BGP Autonomous System Confederations for BGP Статус документа В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений. Авторские права Copyright (C) The Internet Society (2001). All Rights Reserved. Тезисы Протокол BGP¹ представляет собой протокол маршрутизации между автономными системами, разработанный для сетей TCP/IP². BGP требует, чтобы все узлы BGP в одной автономной системе (AS) были связаны между собой (fully meshed - “каждый с каждым”). Это требование порождает серьезные проблемы масштабирования, отмеченные в многочисленных документах. Данный документ описывает расширение BGP, которое может использоваться для создания конфедерации автономных систем, представляющихся как единая АС для узлов BGP, не входящих в конфедерацию. Это позволяет решить проблему “полносвязности”. Смысл этого расширения состоит в расширении возможностей управления политикой и упрощения поддержки больших автономных систем. *1. Спецификация требований* Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119]. *2. Введение* В соответствии со спецификацией протокол BGP требует, чтобы каждый узел BGP в одной AS имел соединения со всеми другими узлами BGP в этой автономной системе (fully meshed). Результатом этого является необходимость поддержки каждым узлом BGP (в автономной системе с числом узлов n) n(n-1)/2 уникальных сессий IBGP. Это требование “полносвязности” создает проблемы масштабирования для АС с большим числом узлов IBGP, обычным для многих современных сетей. Эта проблема масштабирования описана во множестве документов и существует целый ряд предложений по ослаблению проблемы [3,5]. В этом документе предлагается дополнительный способ ослабления проблемы полносвязности, известный как "Autonomous System Confederations for BGP³" или просто "BGP Confederations⁴". Можно также сказать, что конфедерации BGP могут* повышать эффективность управления политикой маршрутизации. Этот документ является пересмотром RFC 1965 [4] и включает редакторские правки, разъяснения и корректировки, основанные на опыте развертывания BGP Confederations. Изменения по сравнению с упомянутым документом перечислены в Приложении A. *3. Термины и определения* AS Confederation Группа автономных систем, анонсируемых с общим номером AS узлам BGP, не входящим в данную конфедерацию. AS Confederation Identifier Видимый снаружи номер автономной системы, идентифицирующий конфедерацию в целом.

	¹Border Gateway Protocol ²Transmission Control Protocol/Internet Protocol ³Конфедерации автономных систем для BGP ⁴BGP-конфедерации rfc.com.ru			rfc.com.ru



		Перевод RFC 3065
		Перевод RFC 3065
	Member-AS Автономная система, включенная в данную конфедерацию AS. Member-AS Number Номер автономной системы, видимый только членам данной конфедерации BGP. *4. Обсуждение* Может оказаться полезным деление автономных систем с большим числом узлов BGP на более мелкие домены в целях управления политикой маршрутизации с помощью данных, содержащихся в атрибуте BGP AS_PATH. Например, можно рассматривать все узлы BGP в неком географическом регионе как единый объект. Кроме потенциального повышения уровня контроля за политикой маршрутизации (если не используются методы типа описанного здесь или в документе [5]) спецификация протокола [1] требует, чтобы все узлы BGP одной автономной системы организовали полносвязную (full mesh) систему соединений TCP со всеми другими узлами для обмена внешней маршрутной информацией. В автономных системах число внутридоменных соединений, которые должен поддерживать каждый граничный маршрутизатор, может становиться весьма значительным. Деление автономной системы на части позволяет существенно снизить общее число внутридоменных соединений BGP, поскольку в этом случае требования связности упрощаются до уровня модели, используемой для междоменных соединений. К сожалению деление автономной системы на части может увеличить сложность реализации политики маршрутизации на основе данных из атрибутов AS_PATH для всех членов Internet. Кроме того, это деление увеличит издержки на управление и координацию внешних партнерских связей при изменении внутренней топологии этого множества автономных систем. И, наконец, деление больших AS может привести к неоправданному увеличению размера упорядоченной части атрибута AS_PATH. Некоторые распространенные реализации BGP могут использовать число “интервалов между AS” (AS hops) до данного адресата, как часть критерия выбора пути. Хотя такой метод определения предпочтительного маршрута не является оптимальным, при нехватке других данных он обеспечивает разумное поведение “по умолчанию”, широко используемое в сети Internet. Следовательно, деление автономной системы на отдельные фрагменты может оказать существенное влияние на уровень оптимальности маршрутизации пакетов через Internet. Однако обычно не возникает необходимости в раскрытии внутренней топологии таких поделенных на части автономных систем и это означает, что возможно представление множества автономных систем с единым администрированием как единого объекта или AS с точки зрения находящихся за пределами данной конфедерации автономных систем. *5. Расширение AS_CONFED для типа сегмента* В действующей спецификации BGP сказано, что атрибут AS_PATH является хорошо известным обязательным атрибутом, состоящим из последовательности сегментов пути (AS path segment). Каждый сегмент пути представляется триплетом <path segment type, path segment length, path segment value>. В соответствии с [1] тип сегмента пути задается однооктетным полем, для которого определены следующие значения: *Значение* *Имя* *Описание* 1 AS_SET Неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE. 2 AS_SEQUENCE Упорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE. В настоящем документе определены два дополнительных типа сегментов пути: *Значение* *Имя* *Описание* AS_CONFED_SEQUENCE Упорядоченный набор номеров Member AS в локальной конфедерации, через которую 3 передается сообщение UPDATE. AS_CONFED_SET Неупорядоченный набор номеров Member AS в локальной конфедерации, через 4 которую передается сообщение UPDATE. *6. Принцип работы* Член конфедерации BGP будет использовать свое значение AS Confederation ID во всех транзакциях с партнерами, которые не являются членами данной конфедерации. Этот идентификатор конфедерации рассматривается как видимый извне номер AS, этот номер используется в сообщениях OPEN и анонсируется в атрибуте AS_PATH. Член конфедерации BGP будет использовать свое значение Member AS Number во всех транзакциях с партнерами, входящими в данную конфедерацию. Узлу BGP, получившему атрибут AS_PATH с номером автономной системы, соответствующим его конфедерации, следует трактовать путь так же, как это делается для путей, содержащих номер AS этого узла. Узлу BGP, получившему атрибут AS_PATH с сегментами AS_CONFED_SEQUENCE или AS_CONFED_SET, содержащими его Member AS Number, следует трактовать путь так же, как это делается для путей, содержащих номер AS этого узла. 6.1. Правила изменения AS_PATH Параграф 5.1.2 документа [1] заменяется приведенным ниже текстом: Когда узел BGP распространяет маршрут, который был получен в сообщении UPDATE от другого узла BGP, ему следует изменить атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут: a) Когда данный узел BGP анонсирует маршрут другому узлу BGP, расположенному в той же автономной системе, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH. b) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, анонсирующему узлу следует изменить связанный с этим маршрутом атрибут AS_PATH как показано ниже: rfc.com.ru 2 rfc.com.ru



Перевод RFC 3065

*Полное заявление авторских прав* Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

*Подтверждение* Финансирование функций RFC Editor обеспечено Internet Society.

rfc.com.ru	5	rfc.com.ru