RFC2008 — Последствия различных политик выделения адресов для маршрутизации в Интернете

Идентификатор и границы фрагмента: RFC2008/part-001, SHA-256=37fc100151101085104675386a012b656738af2228167edce2ba37a246cbddff. От начала документа до незавершённого предложения в разделе 5.1: “It was assumed that if an organization acquires its addresses via the”.

Рабочая группа сети                                      Y. Rekhter
Запрос комментариев: 2008                                      T. Li
BCP: 7                                                  Cisco Systems
Категория: Лучшая современная практика                  Октябрь 1996

              Последствия различных политик распределения адресов
                         для маршрутизации в Интернете

Статус этого меморандума

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

Примечание IESG:

   Описанные в этом документе ограничения адресации в значительной мере
   являются результатом взаимодействия существующей технологии маршрутизаторов,
   назначения адресов и архитектурной истории. После всестороннего рассмотрения
   и обсуждения авторы этого документа, рабочая группа IETF, рассмотревшая его,
   и IESG пришли к заключению, что в настоящее время отсутствуют другие
   доступные для развёртывания технологии, способные преодолеть эти ограничения.
   Если технология маршрутизации или маршрутизаторов разовьётся до такой степени,
   что достаточная агрегация маршрутов сможет достигаться другими средствами либо
   маршрутизаторы смогут работать с более крупными и более динамичными таблицами
   маршрутизации, эти ограничения, возможно, будет целесообразно пересмотреть.

1 Аннотация

   Распределение и управление одноадресными IP-адресами являются важнейшими
   операционными функциями для публичного Интернета. Точные политики
   распределения и управления одноадресными IP-адресами продолжают быть
   предметом многих обсуждений. Такие обсуждения нельзя вести в вакууме —
   их участники должны понимать технические вопросы и последствия, связанные
   с различными политиками распределения адресов и управления ими.

   Цель этого документа — сформулировать некоторые относящиеся к делу
   фундаментальные технические вопросы, которые необходимо учитывать при
   разработке политик распределения и управления одноадресными адресами для
   публичного Интернета, а также дать рекомендации относительно этих политик.

   Основное внимание в этом документе уделено двум возможным политикам —
   «владению адресами» и «предоставлению адресов взаймы» — и техническим
   последствиям этих политик для публичного Интернета. Для организаций,
   которые могли бы обеспечивать достижимость достаточно большой

Rekhter & Li             Лучшая современная практика            [Страница 1]

RFC 2008                                                    Октябрь 1996

   доли всех адресатов в Интернете и могли бы выражать такую достижимость
   посредством одного префикса IP-адресов, документ предлагает использовать
   политику «владения адресами». Однако применение политики «владения
   адресами» к каждому отдельному сайту или организации, подключающимся к
   Интернету, приводит к немасштабируемой маршрутизации.

   Следовательно, этот документ также рекомендует формально добавить политику
   «предоставления адресов взаймы» к набору политик распределения адресов в
   публичном Интернете. Документ также рекомендует настоятельно поощрять
   организации, которые не обеспечивают достаточной степени агрегации
   маршрутной информации, но желают получить доступ к службам маршрутизации
   Интернета, использовать эту политику для получения доступа к этим службам.

2 О внутренней ценности IP-адресов

   Синтаксически множество одноадресных IPv4-адресов представляет собой
   (конечное) множество целых чисел в диапазоне 0x00000000 - 0xDFFFFFFF.
   IP-адреса используются для маршрутизации сетевого уровня (IP). IP-адрес —
   это единственная часть информации об узле, вносимая в систему маршрутизации.

   Примечательная семантика одноадресного IP-адреса заключается в его
   способности взаимодействовать со службой маршрутизации публичного Интернета
   и тем самым обмениваться данными с остальной частью Интернета. Иными словами,
   для публичного Интернета именно достижимость IP-адреса придаёт ему внутреннюю
   ценность. Следует, однако, заметить, что IP-адреса используются и вне
   публичного Интернета. Этот документ не рассматривает ценность адресов в
   контексте, отличном от публичного Интернета.

   Сказанное выше подразумевает, что в публичном Интернете внутреннюю ценность
   IP-адресу придаёт среда предоставления услуг (Интернет) и её непрерывная
   работа, включая её систему маршрутизации, а не наоборот. Следовательно,
   если система маршрутизации публичного Интернета перестаёт работать, услуга
   исчезает, а адреса перестают иметь какую-либо функциональную ценность в
   Интернете. В этот момент для публичного Интернета все политики распределения
   адресов и управления ими, включая существующие политики, становятся
   бессмысленными.

3 Иерархическая маршрутизация и её последствия для распределения адресов

   Иерархическая маршрутизация [Kleinrock 77] — это механизм, улучшающий
   свойства масштабируемости системы маршрутизации. Это единственный доказанный
   механизм масштабирования маршрутизации до текущего размера Интернета.

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

Rekhter & Li             Лучшая современная практика            [Страница 2]

RFC 2008                                                    Октябрь 1996

   иерархическая маршрутизация допускает рекурсивное выполнение этого: несколько
   объявлений (маршрутов) могут быть объединены в одно объявление (маршрут).
   При использовании этой рекурсии объём информации, необходимой для обеспечения
   маршрутизации, может быть существенно уменьшен.

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

   Обратите внимание, что эффект для масштабирования огромен. Если рассмотреть
   пространственную сложность различных схем, коммутатору, который знает о
   каждом абоненте в мире, требуется пространство O(n) для n абонентов по всему
   миру. Теперь рассмотрим случай иерархической маршрутизации. Мы можем
   разложить n на число абонентов в локальной зоне (l), другие станции в зоне с
   данным кодом (e), другие коды зон в местном коде страны (a) и другие коды
   стран (c). При такой записи иерархическая маршрутизация имеет пространственную
   сложность O(l + e + a + c). Обратите внимание, что каждый из этих множителей
   значительно, значительно меньше n и растёт очень медленно, если вообще растёт.
   Это означает, что сегодня можно построить телефонный коммутатор, который имеет
   некоторую надежду не исчерпать пространство при его развёртывании.

   Фундаментальное свойство иерархической маршрутизации, делающее такую
   масштабируемость возможной, — это способность формировать абстракции: здесь —
   способность группировать абонентов в станции, зоны с кодами и коды стран.
   Кроме того, такие абстракции должны предоставлять полезную информацию для
   выполнения маршрутизации. Некоторые абстракции, например группа пользователей
   с зелёными телефонами, бесполезны, когда требуется маршрутизировать вызов.

   Поскольку информация, действительно необходимая системе маршрутизации, — это
   положение адреса в топологии, для иерархической маршрутизации полезная
   абстракция должна отражать топологическое положение адреса в сети. В принципе
   это можно осуществить одним из двух способов. Либо (a) ограничить топологию
   (и разрешённые изменения топологии) так, чтобы она соответствовала назначению
   адресов. Либо (b) избежать ограничений на топологию (и изменения топологии),
   но требовать, чтобы при изменении топологии изменялся и адрес сущности.
   Процесс изменения адреса сущности известен как «перенумерация».

Rekhter & Li             Лучшая современная практика            [Страница 3]

RFC 2008                                                    Октябрь 1996

4 Масштабирование системы маршрутизации Интернета

   Огромный рост публичного Интернета создаёт большую нагрузку на систему
   маршрутизации Интернета. До внедрения CIDR темп роста примерно каждые девять
   месяцев удваивал размер таблицы маршрутизации. Возможности компьютерной
   техники примерно удваиваются каждые 24 месяца. Даже если бы мы могли
   удваивать возможности маршрутизаторов в Интернете каждые 24 месяца, размер
   таблиц маршрутизации неизбежно превысил бы предел возможностей маршрутизаторов.
   Поэтому для сохранения непрерывного роста публичного Интернета необходимо
   развёртывание механизмов, сдерживающих темп роста маршрутной информации.

   При отсутствии механизмов сдерживания темпа роста маршрутной информации рост
   Интернета пришлось бы либо ограничить, либо заморозить, либо система
   маршрутизации Интернета была бы перегружена. Результат перегрузки маршрутизации
   состоит в отказе подсистемы маршрутизации: либо оборудование (маршрутизаторы)
   не сможет поддерживать достаточно маршрутов для обеспечения глобальной
   связности, либо провайдеры просто исключат определённые маршруты, чтобы
   обеспечить связность посредством других маршрутов с конкретными сайтами.
   Этот документ исходит из того, что ни один из упомянутых в этом абзаце
   результатов не приемлем.

   Бесклассовая междоменная маршрутизация (CIDR) [RFC1518, RFC1519] развёрнута
   в публичном Интернете с конца 1992 года как основной механизм сдерживания
   темпа роста маршрутной информации — без CIDR система маршрутизации Интернета
   уже бы разрушилась. Например, в октябре 1995 года в AlterNet (одном из
   крупных поставщиков интернет-услуг) насчитывалось 3194 маршрута. Благодаря
   агрегации AlterNet объявляла остальной части Интернета лишь 799 маршрутов —
   сокращение на 2395 маршрутов (75%) [Partan 95]. В октябре 1995 года реестр
   маршрутизации Интернета (IRR) содержал 61 430 перечисленных уникальных
   префиксов, не считая префиксов, помеченных как отозванные (или 65 191 префикс
   с префиксами, помеченными как отозванные). Это примерно нижняя граница,
   поскольку многие префиксы не зарегистрированы в IRR. Агрегация CIDR привела
   к менее чем 30 000 маршрутов в части системы маршрутизации Интернета без
   маршрута по умолчанию [Villamizar 95].

   CIDR — пример применения иерархической маршрутизации в публичном Интернете,
   где подсети, абоненты и, наконец, провайдеры являются некоторыми возможными
   уровнями иерархии. Например, маршрутизатору внутри сайта не нужно хранить
   подробную маршрутную информацию о каждом возможном хосте на этом сайте.
   Вместо этого маршрутизатор поддерживает маршрутную информацию для каждой
   подсети. Аналогично, маршрутизатору внутри провайдера не нужно хранить
   подробную маршрутную информацию об отдельных подсетях своих абонентов.
   Вместо этого маршрутизатор мог бы поддерживать маршрутную информацию для
   каждого абонента. Более того, маршрутизатору внутри провайдера не нужно
   хранить подробную маршрутную информацию о тупиковых (однодомных) абонентах
   других провайдеров, поддерживая маршрутную информацию для каждого провайдера.

Rekhter & Li             Лучшая современная практика            [Страница 4]

RFC 2008                                                    Октябрь 1996

   Из-за распределения адресов до CIDR многие маршруты в Интернете не подходят
   для иерархической агрегации. Более того, существуют неподключённые сайты с
   распределениями адресов до CIDR. Если эти сайты в какой-то момент в будущем
   подключатся к Интернету, маршруты к ним, вероятно, не будут пригодны для
   иерархической агрегации. Также, когда сайт использует адреса, полученные от
   своего провайдера, но позднее переходит к другому провайдеру (продолжая
   использовать те же адреса), маршрут к сайту может более не быть пригодным
   для иерархической агрегации.

   Иерархическая маршрутизация требует, чтобы границы агрегации адресной
   информации формировались в соответствии с некоторой иерархией. В результате
   в будущем, помимо существующих в настоящее время исключений, в систему
   маршрутизации будет вноситься много исключений. Каждое исключение, добавленное
   в систему маршрутизации, препятствует масштабируемости системы маршрутизации.
   Точное число исключений, которое может быть допустимо, зависит от технологии,
   используемой для поддержки маршрутизации. Неконтролируемый рост числа таких
   исключений приведёт к разрушению системы маршрутизации.

5 Политики распределения адресов и управления ими

   Политика распределения IP-адресов и управления ими — сложный,
   многосторонний вопрос. Она охватывает широкий круг вопросов, таких как: кто
   формулирует политики, кто исполняет политики, какова роль различных реестров,
   какова роль различных организаций (например, ISOC, IAB, IESG, IETF, IEPG,
   различных государственных органов и т. д.), участие конечных пользователей в
   запросе адресов и так далее. Распределение адресов и управление ими, а также
   масштабируемость системы маршрутизации взаимосвязаны: только определённые
   политики распределения адресов и управления ими обеспечивают масштабируемую
   маршрутизацию. Система маршрутизации Интернета подвержена как технологическим,
   так и фундаментальным ограничениям. Эти ограничения сужают выбор практически
   применимых политик распределения адресов.

5.1 Политика распределения «владение адресами» и её последствия для
   публичного Интернета

   «Владение адресами» — одна из возможных политик распределения адресов и
   управления ими. Политика «владения адресами» означает, что часть адресного
   пространства после выделения организации остаётся выделенной этой организации
   столько времени, сколько организация этого желает. Кроме того, эта часть
   адресного пространства не будет выделена никакой другой организации. Часто
   такие адреса называют «переносимыми». Предполагалось, что если организация
   получает свои адреса через

Rekhter & Li             Best Current Practice                  [Страница 5]

RFC 2008                                                    Октябрь 1996

   политики «владения адресами» организация могла бы использовать эти
   адреса для получения доступа к службам маршрутизации Интернета
   независимо от того, где организация подключается к Интернету.

   Хотя никогда явно не утверждалось, что различные реестры Интернета
   используют политику распределения «владения адресами», это всегда
   предполагалось (и применялось на практике).

   Чтобы понять последствия политики «владения адресами» («переносимых»
   адресов) для масштабируемости системы маршрутизации Интернета,
   необходимо отметить следующее:

     (a) По определению, владение адресами предполагает, что адреса после
     назначения переходят под контроль получателя назначения. Именно
     получатель назначения решает, когда отказаться от владения (хотя
     на это решение могут влиять различные факторы). В частности,
     получатель назначения не обязан (но на него могут влиять)
     отказываться от владения при изменении его подключения к
     Интернету.

     (b) По определению, иерархическая маршрутизация предполагает, что
     адреса максимально возможно отражают топологию сети.

   Поэтому единственный известный в настоящее время практически
   осуществимый способ одновременно обеспечить масштабируемую
   иерархическую маршрутизацию и владение адресами для всех состоит в
   предположении, что топология (или по меньшей мере некоторые её части)
   будет постоянно фиксированной. Учитывая распределённый,
   децентрализованный, в значительной степени нерегулируемый и
   глобальный (международный) характер Интернета, ограничение топологии
   Интернета (или даже некоторых её частей) может иметь широкие
   технические, социальные, экономические и политические последствия.
   На сегодняшний день мало известно о том, каковы эти последствия; ещё
   меньше известно о том, будут ли эти последствия приемлемы
   (осуществимы) на практике. Поэтому, по крайней мере пока, нам
   необходимо поддерживать Интернет с неограниченной топологией (и
   неограниченными топологическими изменениями).

   Поскольку Интернет не ограничивает свою топологию (или допустимые
   изменения топологии), мы можем либо иметь владение адресами для всех,
   либо маршрутизируемый Интернет, но не то и другое одновременно, либо
   нам необходимо разработать и развернуть новые механизмы (например,
   отделив адреса, принадлежащие конечным пользователям, от адресов,
   используемых маршрутизацией Интернета, и предоставив механизмы
   преобразования между ними). При отсутствии новых механизмов, если мы
   обеспечим владение адресами («переносимые» адреса) для всех, то
   накладные расходы маршрутизации приведут к отказу системы
   маршрутизации и, как следствие, к фрагментированному
   (разделённому на части) Интернету. В качестве альтернативы мы можем
   иметь маршрутизируемый Интернет, но без владения адресами
   («переносимых» адресов) для всех.




Rekhter & Li             Best Current Practice                  [Страница 6]

RFC 2008                                                    Октябрь 1996

5.2 Политика распределения «предоставления адресов взаймы» и её
   последствия для публичного Интернета

   В последнее время, особенно с появлением CIDR, некоторые абоненты и
   поставщики следовали модели, в которой адресное пространство не
   принадлежит получателю (не является переносимым), а привязано к
   топологии. Эта модель предполагает политику распределения адресов и
   управления ими, отличающуюся от политики «владения адресами». Ниже
   описывается политика, называемая «предоставлением адресов взаймы»,
   которая лучше соответствует модели по сравнению с политикой
   «владения адресами».

   Политика «предоставления адресов взаймы» означает, что организация
   получает свои адреса на условиях «займа». В течение срока займа
   заимодавец не может передавать эти адреса взаймы другому заёмщику.
   Назначения и распределения, основанные на политике «предоставления
   адресов взаймы», следует явно включать условия займа. Такие условия
   должны устанавливать, что распределения возвращаются, если
   заёмщик более не связан договорными обязательствами с заимодавцем и
   заимодавец более не может обеспечить агрегацию для распределения.
   Если срок займа заканчивается, организация более не может
   использовать взятые взаймы адреса и поэтому должна получить новые
   адреса и выполнить перенумерацию для их использования. Политика
   «предоставления адресов взаймы» не ограничивает способы получения
   новых адресов.

   В этом документе предполагается, что политика «предоставления
   адресов взаймы» будет использоваться прежде всего реестрами
   Интернета, связанными с поставщиками; однако этот документ не
   исключает использования политики «предоставления адресов взаймы»
   реестром Интернета, не связанным с поставщиком.

   В этом документе предполагается, что, когда политика «предоставления
   адресов взаймы» используется реестром Интернета, связанным с
   поставщиком, поставщик отвечает за организацию агрегации этих адресов
   в степени, достаточной для обеспечения IP-связности в масштабе всего
   Интернета.

   В этом документе предполагается, что, когда политика «предоставления
   адресов взаймы» используется реестром Интернета, связанным с
   поставщиком, положения и условия займа будут связаны с соглашением об
   обслуживании между поставщиком и абонентами. То есть, если абонент
   переходит к другому поставщику, займ будет отменён.








Rekhter & Li             Best Current Practice                  [Страница 7]

RFC 2008                                                    Октябрь 1996

   Чтобы уменьшить нарушения работы, когда абонент меняет поставщика,
   этот документ настоятельно рекомендует, чтобы положения и условия
   займа включали условие о льготном периоде. Это условие предоставляло
   бы абоненту, отключившемуся от своего поставщика, определённый
   льготный период после отключения. В течение этого льготного периода
   заёмщик (абонент) может продолжать использовать адреса, полученные на
   условиях займа. Этот документ рекомендует льготный период не менее
   30 дней. Кроме того, чтобы сдерживать накладные расходы, связанные с
   информацией маршрутизации, этот документ предлагает, чтобы льготный
   период не превышал шести месяцев.

   Чтобы понять последствия политики «предоставления адресов взаймы»
   для масштабируемости, отметим, что, если абонент берёт свои адреса
   взаймы из блока своего поставщика, поставщик может анонсировать один
   адресный префикс. Это уменьшает объём информации маршрутизации,
   который должна переносить система маршрутизации Интернета (подробнее
   см. раздел 5.3.1 RFC1518). Когда абонент меняет поставщика, займ у
   прежнего поставщика возвращается, а займ у нового поставщика
   оформляется. В результате абонент выполнит перенумерацию на новые
   адреса. После того как абонент перенумеруется в существующие блоки
   нового поставщика, в систему маршрутизации не потребуется вводить
   новые маршруты.

   Поэтому политика «предоставления адресов взаймы» при надлежащем
   применении согласуется с ограничениями на политики распределения
   адресов, налагаемыми иерархической маршрутизацией, и тем самым
   способствует масштабируемой системе маршрутизации. Таким образом,
   политика «предоставления адресов взаймы» при надлежащем применении
   может играть важную роль в обеспечении непрерывного и бесперебойного
   роста Интернета.

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

5.3 При отсутствии явно определённой политики «предоставления адресов
   взаймы»

   Организациям, подключающимся к Интернету, следует осознавать, что,
   даже если их текущий поставщик и поставщик, к которому они перейдут в
   будущем, не требуют перенумерации, перенумерация всё же может
   понадобиться для обеспечения IP-связности в масштабе всего Интернета.
   Например, организация может сейчас получать услуги Интернета от
   некоторого поставщика и выделять свои адреса из CIDR-блока,
   связанного с поставщиком. Позднее организация может перейти к другому
   поставщику. Прежний поставщик всё ещё может быть готов разрешить
   организации сохранить часть CIDR-блока поставщика и принять от нового
   поставщика более специфичный префикс



Rekhter & Li             Best Current Practice                  [Страница 8]

RFC 2008                                                    Октябрь 1996

   для этой организации. Аналогично, новый поставщик может быть готов
   принять эту организацию без перенумерации и анонсировать более
   специфичный префикс (охватывающий назначения внутри организации)
   остальной части Интернета. Однако, если существует один или несколько
   других поставщиков, не желающих или не способных принять более длинный
   префикс, анонсированный новым поставщиком, организация не будет иметь
   IP-связности с частью Интернета. Среди возможных решений, доступных
   организации, могут быть либо перенумерация, либо получение другими
   участниками связности с поставщиками, которые готовы и способны
   принять префикс.

   Приведённое выше показывает, что отсутствие у текущего поставщика
   явно определённой политики «предоставления адресов взаймы» никоим
   образом не гарантирует, что в будущем при смене поставщиков не
   потребуется перенумерация. Организациям следует осознавать этот факт,
   если они столкнутся с поставщиком, заявляющим обратное.

6 Рекомендации

   Отметим, что цель иерархической маршрутизации в Интернете состоит не
   в уменьшении общего объёма информации маршрутизации в Интернете до
   теоретически возможного минимума, а лишь в удержании объёма информации
   маршрутизации в пределах, обусловленных технологией,
   соотношением цена/производительность и человеческими факторами.
   Поэтому организации, которые могли бы обеспечить достижимость
   достаточно большой доли общего числа назначений в Интернете и могли
   бы выразить такую достижимость одним префиксом IP-адреса, могли бы
   рассчитывать, что маршрут с этим префиксом будет поддерживаться во
   всей части системы маршрутизации Интернета без маршрута по умолчанию,
   независимо от того, где они подключаются к Интернету. Поэтому
   использование политики «владения адресами» при распределении адресов
   таким организациям является разумным выбором. Внутри таких организаций
   этот документ предлагает использовать политику «предоставления
   адресов взаймы».

   Для всех остальных организаций, ожидающих IP-связности в масштабе
   всего Интернета, информацию о достижимости, которую они вводят в
   систему маршрутизации Интернета, следует подвергать иерархической
   агрегации. Для таких организаций распределение адресов на основе
   политики «владения адресами» делает иерархическую агрегацию трудной,
   если не невозможной. Это, в свою очередь, оказывает крайне
   неблагоприятное воздействие на систему маршрутизации Интернета. Чтобы
   предотвратить коллапс системы маршрутизации Интернета, для таких
   организаций этот документ рекомендует использовать политику
   «предоставления адресов взаймы». Следовательно, когда такая
   организация впервые подключается к публичному Интернету или изменяет
   своё топологическое присоединение к публичному Интернету, организации
   в конечном счёте требуется выполнить перенумерацию. Перенумерация
   позволяет организации отозвать любые исключительные префиксы, которые
   организация иначе вводила бы в систему маршрутизации Интернета. Это
   относится к



Rekhter & Li             Best Current Practice                  [Страница 9]

RFC 2008                                                    Октябрь 1996

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

   Передача информации маршрутизации сопряжена с затратами. В некоторый
   момент эти затраты могут быть полностью переложены на организации,
   которые вводят информацию маршрутизации. Агрегация адресной информации
   (посредством CIDR) может снизить затраты, поскольку позволяет
   увеличить число назначений, охватываемых одним маршрутом. Организациям,
   чьи адреса распределены на основе политики «владения адресами» (и
   поэтому могут быть непригодны для агрегации), следует быть готовыми
   полностью нести эти затраты самостоятельно.

   Отметим, что ни политика «владения адресами», ни политика
   «предоставления адресов взаймы» сами по себе не достаточны для
   гарантирования IP-связности в масштабе всего Интернета. Поэтому мы
   рекомендуем площадкам с адресами, распределёнными на основе любой из
   этих политик, консультироваться со своими поставщиками о масштабе
   достижимости, который может быть обеспечен с этими адресами, и о
   связанных с ними затратах, возникающих при использовании этих
   адресов.

   Если организации не требуется IP-связность в масштабе всего
   Интернета, распределение адресов для организации может производиться
   на основе политики «владения адресами». В этом случае организация всё
   ещё может поддерживать ограниченную IP-связность (например, со всеми
   абонентами своего непосредственного поставщика), ограничивая область
   распространения своей информации маршрутизации своим непосредственным
   поставщиком. Связность с остальной частью Интернета может
   обеспечиваться посредством посреднических шлюзов (например, шлюзов
   прикладного уровня, трансляторов сетевых адресов (NAT)). Учтите, что
   использование посреднических шлюзов устраняет необходимость
   перенумерации и позволяет не обременять систему маршрутизации
   Интернета неагрегируемой адресной информацией; однако у них есть
   другие недостатки, которые в некоторых ситуациях могут оказаться
   неудобными.

Как перенумерация (вследствие политики «предоставления адресов во временное пользование»), так и неагрегированная информация о маршрутизации (вследствие политики «владения адресами»), а также использование посреднических шлюзов сопряжены с определёнными затратами. Поэтому организации необходимо тщательно проанализировать собственные требования к подключению и сопоставить компромиссы, связанные с адресами, полученными в рамках любой из политик, с подключением через посреднические шлюзы (возможно, дополненным ограниченной IP-связностью) с использованием адресов, полученных в рамках «владения адресами». Чтобы снизить затраты на перенумерацию, организациям следует настоятельно рекомендовать развертывать средства, упрощающие перенумерацию (например, Dynamic Host Configuration Protocol [RFC 1541]). Следует настоятельно рекомендовать использование DNS.




Rekhter & Li             Best Current Practice                 [Страница 10]

RFC 2008                                                    Октябрь 1996


7 Резюме

Любая политика распределения адресов и управления IP-адресами, используемыми для подключения к Интернету, должна учитывать её влияние на масштабируемость системы маршрутизации Публичного Интернета. Среди всех возможных политик распределения адресов и управления ими осуществимы только те, которые обеспечивают масштабируемую систему маршрутизации. Все остальные политики по своей природе являются саморазрушительными, поскольку приводят к коллапсу системы маршрутизации Интернета, а следовательно, к фрагментации (разделению) Публичного Интернета.

В контексте нынешнего Публичного Интернета политики распределения адресов и управления ими, предполагающие неограниченное владение адресами, оказывают крайне отрицательное влияние на масштабируемость системы маршрутизации Интернета. Такие политики почти наверняка исчерпают масштабируемость системы маршрутизации Интернета задолго до того, как мы приблизимся к исчерпанию адресного пространства IPv4, и до того, как сможем эффективно использовать адресное пространство IPv6. При темпах роста Интернета и нынешнем уровне технологий представление о том, что каждый может владеть адресным пространством и получать услуги маршрутизации в масштабах всего Интернета независимо от места своего подключения к Интернету, в настоящее время технически неосуществимо. Поэтому этот документ даёт две рекомендации. Во-первых, политику «предоставления адресов во временное пользование» следует формально добавить к набору политик распределения адресов в Публичном Интернете. Во-вторых, организациям, которые не обеспечивают достаточную степень агрегации информации о маршрутизации для получения доступа к услугам маршрутизации Интернета, следует настоятельно рекомендовать использовать эту политику для получения доступа к услугам.

Поскольку текущая архитектура распределения адресов IPv6 основана на CIDR, рекомендации, представленные в этом документе, применимы также к политикам распределения адресов IPv6 и управления ими.

8 Соображения безопасности

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

Многие площадки в настоящее время используют системы «межсетевых экранов» для обеспечения грубого контроля доступа из внешних сетей, таких как Интернет, к своим внутренним системам. Такие межсетевые экраны могут принимать решения по контролю доступа на основе заявленного адреса источника пакетов, поступающих в такие системы межсетевых экранов. Если политика межсетевого экрана относится к пакетам, поступающим на межсетевой экран изнутри площадки, то этот межсетевой экран потребуется перенастроить одновременно с перенумерацией самой площадки. Если политика межсетевого экрана относится к пакетам, поступающим на межсетевой экран извне площадки, то такие межсетевые экраны потребуется перенастраивать всякий раз, когда перенумеровывается внешняя площадка, которой предоставлен какой-либо доступ внутрь площадки через межсетевой экран.



Rekhter & Li             Best Current Practice                 [Страница 11]

RFC 2008                                                    Октябрь 1996


Крайне нецелесообразно полагаться на неаутентифицированные IP-адреса источника или назначения при принятии решений по политике безопасности. [Bellovin89] Подмена IP-адреса не представляет сложности при использовании широко доступных систем, таких как персональные компьютеры. Вероятно, более удачный подход предполагал бы использование на межсетевом экране методов IP Security, таких как IP Authentication Header [RFC-1826] или IP Encapsulating Security Payload [RFC-1827], чтобы межсетевой экран мог полагаться на криптографические методы идентификации при принятии решений по своей политике безопасности.

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

Возможны иные соображения безопасности, не охваченные этим документом.

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

Этот документ в значительной степени опирается на различные сообщения из различных списков рассылки. Особая благодарность Noel Chiappa, Dennis Ferguson, Eric Fleischman, Geoff Huston и Jon Postel, чьи сообщения были использованы в этом документе.

Большая часть раздела 5.3 была подготовлена Curtis Villamizar. Раздел по безопасности был подготовлен Ran Atkinson.

Большая благодарность Scott Bradner, Randy Bush, Brian Carpenter, Noel Chiappa, David Conrad, John Curran, Sean Doran, Dorian Kim, Thomas Narten, Andrew Partan, Dave Piscitello, Simon Poole, Curtis Villamizar и Nicolas Williams за их рецензирование, замечания и вклад в этот документ.

Наконец, мы хотели бы поблагодарить всех членов Рабочей группы CIDR за их рецензирование и замечания.








Rekhter & Li             Best Current Practice                 [Страница 12]

RFC 2008                                                    Октябрь 1996


9 Ссылки

   [Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol
   Suite", ACM Computer Communications Review, Vol. 19, No. 2, March
   1989.

   [Kleinrock 77] Kleinrock, L., and K. Farouk, K., "Hierarchical
   Routing for Large Networks," Computer Networks 1 (1977), North-
   Holland Publishing Company.

   [Partan 95] Partan, A., private communications, October 1995.

   [RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", October
   1993.

   [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
   Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
   Strategy", September 1993.

   [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
   Allocation with CIDR", September 1993.

   [RFC 1825] Atkinson, R., "IP Security Architecture", RFC 1825, August
   1995.

   [RFC 1826] Atkinson, R., "IP Authentication Header (AH), RFC 1826,
   August 1995.

   [RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
   RFC 1827, August 1995.

   [Villamizar 95] Villamizar, C., private communications, October 1995.

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

      Yakov Rekhter
      cisco Systems, Inc.
      170 Tasman Dr.
      San Jose, CA 95134
      Phone: (914) 528-0090
      EMail: yakov@cisco.com

      Tony Li
      cisco Systems, Inc.
      170 Tasman Dr.
      San Jose, CA 95134
      Phone: (408) 526-8186
      EMail: tli@cisco.com



Rekhter & Li             Best Current Practice                 [Страница 13]