Network Working Group                                     Y. Rekhter
Request for Comments: 1518    T.J. Watson Research Center, IBM Corp.
Category: Standards Track                                      T. Li
                                                       cisco Systems
                                                             Editors
                                                      September 1993

Архитектура распределения адресов IP для CIDR

An Architecture for IP Address Allocation with CIDR

PDF

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

В данном RFC содержится спецификация стандарта, предложенного сообществу Internet; документ служит приглашением к дискуссии в целях совершенствования и развития протокола. Информацию о текущем состоянии стандартизации для этого протокола вы можете найти в документе “Internet Official Protocol Standards”. Документ может распространяться без ограничений.

1. Введение

В этом документе рассматривается архитектура и план распределения адресов IP в Internet. Архитектура и план должны сыграть важную роль в переводе Internet на использование бесклассового распределения адресов и стратегии агрегирования, описанных в [1].

Адресное пространство IP является дефицитным ресурсом общего пользования, который требует управления на благо сообщества. Управляющие этим ресурсом действуют как хранители. Они несут перед сообществом ответственность за управление адресным пространством для общего блага.

2. Обсуждаемые вопросы

Internet в глобальном масштабе можно представить как множество хостов, связанных между собой прямыми соединениями или системами коммутации. Управление хостами и соединениями, которые составляют глобальные ресурсы Internet, не является однородным и распределено между множеством уполномоченных организаций. Ресурсы, находящиеся под единым административным управлением, образуют домен. Далее в этом документе термины «домен» (domain) и «домен маршрутизации» (routing domain) будут использоваться как синонимы. Домены, которые предоставляют свои ресурсы другим доменам, называются поставщиками сетевых услуг или сервис-провайдерами (network service provider или provider). Домены, пользующиеся ресурсами других доменов, называют пользовательскими (network service subscriber или subscriber). Домен может относиться к провайдерским и пользовательским одновременно.

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

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

Архитектура и рекомендации, приведенные в этом документе, предназначены для незамедлительной реализации. Документ не предлагает долговременного решения типа создания комплексной системы маршрутизации на основе правил.

Решения, требующие внесения существенных изменений или ограничений для существующей топологии, не рассматриваются.

Архитектура и рекомендации, приведенные в этом документе, связаны в первую очередь с крупномасштабным распределением адресов IP в Internet. В документе рассматриваются:

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

Отметим, что существуют технические и административные аспекты распределения адресов IP, которые не рассматриваются в этом документе. К таким аспектам относятся:

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

3. Основы

Приведенная ниже информация поможет разобраться с вопросами распределения адресов IP. Приводится краткое описание процесса маршрутизации IP.

Задача маршрутизации IP может быть разделена на 3 части:

• обмен маршрутной информацией между конечными системами и маршрутизаторами (ARP);
• обмен маршрутными данными между маршрутизаторами одного домена (внутренняя маршрутизация);
• обмен маршрутными данными между доменами (внешняя маршрутизация).

4. IP-адреса и маршрутизация

В данном документе под префиксом IP будет пониматься некое означенное количество старших битов адреса IP, расположенных непрерывно. В документе для указания префиксов IP будут использоваться пары <IP-адрес, IP-маска> – побитовая логическая операция AND, примененная к компонентам пары, дает в результате непрерывную последовательность старших битов, которые и образуют префикс IP. Например, пара <193.1.0.0 255.255.0.0> указывает 16-битовый префикс.

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

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

Абстрагирование маршрутных данных происходит на границе между иерархически расположенными топологическими структурами маршрутизации. Элементы нижнего уровня иерархии передают вышележащему (родительскому) уровню сводную информацию о маршрутах.

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

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

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

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

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

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

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

4.1 Эффективность и децентрализация

Если в Internet планируется поддержка децентрализованного распределения адресов [4], возникает необходимость в обеспечении баланса требований к распределению адресов IP для эффективной маршрутизации и децентрализованного администрирования. Предложения, описанные в документе [3], могут служить примером баланса.

Префикс IP <198.0.0.0 254.0.0.0> предоставлен для децентрализованного администрирования. Этот префикс идентифицирует часть адресного пространства IP, выделенного для Северной Америки. Адреса из этого блока распределяются с учетом топологических границ для повышения уровня абстракции данных. Клиенты из Северной Америки используют блоки адресов IP, которые являются частями адресного пространства, выделенного их провайдерам. Внутри домена маршрутизации адреса подсетей и хостов выделяются из уникального префикса IP, связанного с доменом.

5. Администрирование адресов IP и маршрутизация в Internet

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

Возникает вопрос – где следует администрировать адреса с учетом описанного отображения, чтобы обеспечить децентрализацию и абстракцию данных? Существует несколько вариантов:

• в какой-либо части домена маршрутизации;
• в ветви домена маршрутизации;
• в транзитном домене маршрутизации (TRD¹);
• на границах континент.

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

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

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

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

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

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

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

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

5.1 Администрирование адресов IP в домене

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

Описанная ситуация весьма напоминает текущую картину Internet³, когда каждый домен может включать множество не связанных между собой адресных блоков. Это является результатом распределения для подсетей не связанных блоков IP в рамках плоской модели⁴ в адресами классов A/B/C. Число префиксов, анонсируемых ветвями доменов маршрутизации, совпадает по порядку величины с числом подключенных сетей, а число префиксов, анонсируемых провайдером, совпадает по порядку величины с числом сетей, подключенных к ветвям домена маршрутизации. Магистральные же сети анонсируют префиксы от всех подключенных провайдеров. Такая ситуация как-то приемлема для текущего состояния Internet, но рост сети быстро приведет к трудноразрешимым проблемам. Для продолжения роста Internet необходимо использование иерархической модели с агрегированием маршрутов.

5.2 Администрирование для ветви домена маршрутизации

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

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

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

5.3 Администрирование для транзитных доменов

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

5.3.1 Прямые сервис-провайдеры

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

В качестве примера рассмотрим прямого сервис-провайдера, обслуживающего 100 клиентов. Если каждый клиент получает свои адреса из 4 независимых блоков, общее число маршрутных записей для этих клиентов составит 400 (100 по 4 префикса). Если каждый клиент получает адреса из одного блока, количество записей для клиентов уменьшается до 100. Если же все клиенты получают адреса из общего блока, число записей уменьшается до 1.

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

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

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

Механизм этого процесса очень прост. Каждый прямой провайдер получает уникальный набор префиксов IP, из которого для подключенных к провайдеру сетей могут выделяться более длинные префиксы IP. Предположим для примера, что NIST является ветвью домена маршрутизации, подключенной через провайдера SURANet. Если SURANet выделен уникальный префикс IP <198.1.0.0 255.255.0.0>, NIST может использовать уникальный префикс <198.1.0.0 255.255.240.0>.

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

5.3.2 Косвенные провайдеры (магистральные сети)

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

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

5.4 Многодомные маршрутные домены

В параграфе 5.3 рассматривалось выделение адресов IP с учетом подключения к прямым и косвенным провайдерам. Это позволяет добиться существенного снижения объемов маршрутной информации для маршрутных доменов, которые подключены к одному TRD. В частности, такие домены могут выбирать свои адреса IP из пространства, выделенного им прямым провайдером. Это позволяет провайдеру при анонсировании доступных адресов другим провайдерам использовать один адресный префикс для большого количества IP-адресов, соответствующих множеству маршрутных доменов.

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

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

Для примера предположим, что крупная северо-американская компания Mega Big International Incorporated (MBII) имеет единую внутреннюю сеть с префиксом, выделенным из северо-американского блока. Очевидно, что за пределами Северной Америки в таблицах маршрутизации может поддерживаться одна запись для всего северо-американского префикса. Однако внутри Северной Америки каждый провайдер должен поддерживать отдельную запись для MBII. Если MBII фактически является международной корпорацией, тогда поддержка отдельной записи для нее может потребоваться от провайдеров всего мира (включая магистрали, к которым MBII не подключена). Очевидно, что такое решение приемлемо при небольшом количестве таких многодомных доменов маршрутизации и будет приводить к недопустимой нагрузке на магистральные маршрутизаторы, если все организации начнут использовать такую схему получения адресов. Это решение не подходит для сетей, в которых число многодомных организаций измеряется сотнями тысяч.

Другим вариантом для многодомных организаций является получение раздельных блоков IP-адресов для каждого соединения с TRD и выделения единого префикса для некоторого подмножества домена (доменов) этой организации в соответствии с ближайшей точкой подключения. Например, если MBII имеет соединения с двумя провайдерами в США (одно на западном побережье, другое на восточном), а также с тремя национальными магистралями в Европе и одной на дальнем востоке, тогда MBII может использовать шесть различных префиксов. Каждая часть MBII будет получать единый префикс в зависимости от ближайшей точки подключения.

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

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

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

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

Отметим, что доставка пакетов для первого и второго варианта будет происходить по разным путям. В первом варианте пакеты, адресованные снаружи в сеть MBII, будут доставляться через точку, которая ближе к отправителю, что приведет к увеличению нагрузки на внутреннюю сеть MBII. Во втором варианте пакеты, направленные в MBII извне, будут доставляться через точку, которая ближе к получателю, что приведет к снижению нагрузки на сеть MBII и росту нагрузки на TRD.

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

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

Существует по крайней мере одна ситуация, в которой третий вариант применим на практике. Предположим, что группа организаций со связанными интересами, реализовала каждая свою опорную сеть. Для примера предположим, что U.S. National Widget Manufacturers and Researchers организовала опорную сеть в масштабах США, которая используется корпорациями, производящими приборы, и некоторыми университетами, занимающимися разработкой приборов. Мы можем ожидать, что различные организации этой группы будут использовать свои внутренние сети, как отдельные домены маршрутизации и большинство из них будет также подключено к другим TRD (поскольку большинство организаций, связанный с производством и разработкой приборов, вовлечены также в другие сферы деятельности). Мы можем, следовательно, ожидать, что многие или большинство из этих организаций являются двудомными с подключением к «приборной сети» и какой-либо иной сети. Предположим также, что общее число организаций в приборной группе достаточно мало для того, чтобы можно было поддерживать таблицу маршрутизации, содержащую по одной записи для каждой организации, но эта таблица распространяется через более крупные сети со многими миллионами (не связанных с приборами) доменов маршрутизации.

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

Четвертый вариант распределения префиксов для доменов маршрутизации используется в тех случаях, когда домены подключены к двум (или большему числу) конкретным доменам маршрутизации. Предположим, например, что имеется два провайдера SouthNorthNet и NorthSouthNet, которые имеют в целом очень большое количество заказчиков (т. е., имеется большое число доменов маршрутизации, подключенных к обоим провайдерам). Вместо получения двух префиксов эти провайдеры могут взять три. Маршрутным доменам, подключенным только к провайдеру NorthSouthNet, будут выделяться адреса из одного префикса, подключенным только к SouthNorthNet – из другого, а подключенным к обоим провайдерам – из третьего. Каждый из двух TRD будет тогда анонсировать в другой TRD два префикса – один для маршрутных доменов, подключенных только к этому провайдеру, а другой – для доменов, подключенных к обоим провайдерам.

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

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

В дополнение к сказанному отметим, что большинство решений также указывают для каждого TRD необходимость выработки политики и условий восприятия адресов, не относящихся к их префиксам, и трактовки таких нелокальных адресов. Например, достаточно консервативная политика может заключаться в том, что нелокальные префиксы IP будут приниматься от любых подключенных краевых (leaf) доменов маршрутизации, но не будут анонсироваться другим TRD. При менее консервативной политике TRD может принимать такие нелокальные адреса и соглашаться обмениваться ими с определенным набором других TRD (этот набор может быть группой TRD, имеющих нечто общее – географическое положение или соглашения, принятые специально по запросу краевых доменов маршрутизации). Различные правила имеют реальную стоимость для TRD, которая может быть отражена в этих правилах.

5.5 Частные каналы

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

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

В качестве примера предположим, что корпорация XYZ имеет тесные деловые контакты с MBII. В этом случае XYZ и MBII могут заключить с провайдером контракт на организацию соединения между двумя корпорациями и этот канал будет использоваться только для передачи пакетов, отправитель которых находится в одной из этих корпораций, а получатель – в другой. Предположим также, что канал «точка-точка» организован между одним маршрутизатором (X) в корпорации XYZ и одним маршрутизатором (M) в MBII. Следовательно, требуется настроить маршрутизатор X так, чтобы он знал, какие адреса доступны через данный канал (в данном случае – все адреса MBII). Точно так же требуется настроить маршрутизатор M, которому тоже нужно знать адреса, доступные через соединение (все адреса в корпорации XYZ).

Важно отметить, что такое дополнительное соединение через частный канал может не приниматься во внимание при распределении адресов IP и не будет создавать проблем для маршрутизации. Это связано с тем, что маршрутная информация для такого соединения не распространяется через Internet и, следовательно, не привязана к префиксу TRD.

Возвращаясь к нашему примеру, предположим, что корпорация XYZ имеет одно соединение с региональным оператором и, следовательно, использует пространство адресов IP из выделенного этому региону блока. Далее предположим, что MBII является международной корпорацией с подключением к 6 различным провайдерам, которая выбрала второй из описанных в параграфе 5.4 вариантов и, следовательно, получила шесть разных блоков адресов. В этом случае все адреса, доступные в сети XYZ, можно описать одним префиксом (это предполагает, что достаточно указать в конфигурации маршрутизатора M единственный префикс, который будут представлять все адреса, доступные через данное соединение). Доступные адреса MBII могут быть описаны шестью префиксами (это предполагает, что в конфигурации маршрутизатора X требуется указать шесть адресных префиксов для представления адресов, доступных через данное соединение).

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

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

5.6 Изолированные маршрутные домены

В настоящее время очень большое число организаций имеет соединенные между собой сети, которые не подключены ни к одному из сервис-провайдеров. Такие организации, однако, могут иметь множество частных каналов, используемых для соединения с другими организациями. Эти организации не участвуют в глобальной маршрутизации и удовлетворяются доступностью тех организации, с которыми у них имеются соединения по частным каналам. Такие организации называют изолированными (zero-homed) доменами маршрутизации.

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

Однако весьма важно, чтобы изолированные домены использовали корректные и уникальные в глобальном масштабе адреса IP. Предположим, что изолированный домен соединен частным каналом с другим доменом маршрутизации. Этот домен, в свою очередь, соединен с сетью, использующей уникальные в глобальном масштабе адреса IP. Данный домен должен иметь возможность различать адреса IP в изолированном домене от всех прочих IP-адресов, к которым он имеет маршруты. Единственным способом гарантированно обеспечить такое различие является использование в изолированном домене уникальных в глобальном масштабе адресов IP⁶.

5.7 Континентальное агрегирование

В целях дальнейшего снижения объемов данных, требуемых для междоменной маршрутизации, может использоваться еще один уровень иерархии. Континентальное агрегирование может оказаться весьма полезным, поскольку границы континентов определяют естественные барьеры для топологии соединений и административных границ. Таким образом, это создает естественную границу для другого уровня агрегирования данных междоменной маршрутизации. Для решения этой задачи нужно сделать так, чтобы каждый континент получил соответствующее подмножество адресного пространства. Провайдеры (как прямые, так и косвенные) каждого континента будут получать адресные блоки из таких подмножеств. Отметим, что эта схема имеет множество исключений, когда сервис-провайдеры (как прямые, так и косвенные) работают на нескольких континентах одновременно. Эти исключения должны рассматриваться аналогично ситуациям с многодомными доменами маршрутизации, описанным выше.

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

Для примера предположим, что Европе выделен префикс <194.0.0.0 254.0.0.0> так, что европейская маршрутизация включает также более длинные префиксы <194.1.0.0 255.255.0.0> и <194.2.0.0 255.255.0.0>. Все более длинные европейские префиксы могут быть анонсированы через трансатлантический канал в Северную Америку. Маршрутизатор в Северной Америке будет агрегировать эти маршруты и анонсировать только один префикс <194.0.0.0 255.0.0.0> в северо-американскую систему маршрутизации. Пакеты, адресованные хосту 194.1.1.1 будут проходить через северо-американскую систему маршрутизации и сталкиваться с маршрутизатором, который выполнял агрегирование европейских префиксов. Если префикс <194.1.0.0 255.255.0.0> недоступен, маршрутизатор будет отбрасывать эти пакеты и передавать сообщения ICMP Unreachable без загрузки трансатлантического канала.

5.8 Проблемы смены адресов

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

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

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

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

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

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

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

Для примера предположим, что корпорация XYZ была изначально подключена только к региональной сети NorthSouthNet. Представители XYZ обратились к администрации NorthSouthNet и получили префикс IP, из пространства, выделенного на региональную сеть NorthSouthNet. Однако по ряду причин корпорация XYZ решила разорвать контракт с NorthSouthNet и напрямую подключиться к сети общего пользования NewCommercialNet. В результате перехода корпорация XYZ получила префикс IP из адресного пространства NewCommercialNet. Старый префикс XYZ предполагает, что трафик для XYZ следует маршрутизировать в сеть NorthSouthNet, которая больше не имеет прямого соединения с корпорацией XYZ.

Если прежний TRD (NorthSouthNet) и новый TRD (NewCommercialNet) являются смежными и могут кооперироваться, переход может быть очень простым. В этом случае пакеты, маршрутизируемые в XYZ по старым адресам, могут направляться в сеть NorthSouthNet, которая будет напрямую пересылать их в сеть NewCommercialNet, а та, в свою очередь, в XYZ. В этом случае только сетям NorthSouthNet и NewCommercialNet требуется знать, что старые адреса указывают на получателей, которые более не подключены непосредственно к NorthSouthNet.

Если старый и новый TRD не являются смежными, ситуация несколько осложняется, но по-прежнему существует несколько способов организации корректной пересылки трафика.

Если старый и новый TRD соединены между собой через другие транзитные домены, эти промежуточные домены могут согласовать корректную пересылку трафика для XYZ. В качестве примера предположим, что сети NorthSouthNet и NewCommercialNet не соединены напрямую, но обе подключены к магистральной сети BBNet. В этом случае всем трем сетям NorthSouthNet, NewCommercialNet и BBNet нужно будет поддерживать специальную запись для XYZ, чтобы трафик, направленный по старым адресам корпорации XYZ, пересылался через сеть NewCommercialNet. Однако остальным доменам маршрутизации не требуется знать о новом местоположении XYZ.

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

Те организации, которые ведут достаточно много дел с корпорацией XYZ, также могут включить специальную запись в свои таблицы маршрутизации для обеспечения оптимальной маршрутизации пакетов в сеть XYZ. Для примера предположим, что некая коммерческая магистральная сеть OldCommercialNet имеет множество заказчиков, обменивающихся трафиком с XYZ и эта третья сеть TRD напрямую связана как с NorthSouthNet, так и с NewCommercialNet. В этом случае OldCommercialNet будет сохранять одну запись для всего трафика, адресованного в NorthSouthNet, но в таблицу может быть добавлена одна (более специфичная) запись для обеспечения корректной маршрутизации пакетов, направленных по старым адресам XYZ.

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

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

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

5.9 Взаимодействие с маршрутизацией на основе правил

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

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

Мы полагаем, что нынешний экспоненциальный рост Internet будет сохраняться или даже ускорится в обозримом будущем. Кроме того, мы ожидаем стремительной интернационализации Internet. Возможность масштабирования системы маршрутизации зависит от использования абстракции данных, основанной на иерархической адресации IP. Поскольку в Internet вводится архитектура CIDR [1], выбор иерархической структуры IP-адресации следует делать с большой осторожностью.

В интересах всего сетевого сообщества сохранять издержки на минимально возможном уровне. В случае распределения адресов IP это снова говорит о важности поддержки абстрагирования маршрутной информации.

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

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

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

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

6.1 Рекомендации для плана распределения адресов

Мы ожидаем, что публичные соединения между частными доменами маршрутизации будут обеспечиваться различными TRD, включая (но не ограничиваясь):

• магистральные (backbone) сети (Alternet, ANSnet, CIX, EBone, PSI, SprintLink);
• множество региональных и национальных сетей;
• множество коммерческих общедоступных сетей (PDN⁷).

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

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

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

Для поддержки континентального агрегирования адресов мы рекомендуем для всех TRD на каждом континенте выделять адреса из соответствующих континентальных префиксов.

Предлагаемая в этом документе схема распределения адресов предполагает, что часть пространства адресов IP следует выделить для каждого TRD (явно включая магистральные и региональные сети). Для тех краевых доменов маршрутизации, которые соединенны с одним TRD, следует выделять префиксы из адресного пространства соответствующих TRD.

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

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

6.2 Рекомендации для многодомных доменов маршрутизации

Для многодомных доменов маршрутизации существует несколько возможных вариантов, описанных в параграфе 5.4. Эти методы различаются объемом информации, которую нужно поддерживать для обеспечения междоменной маршрутизации, а также организацией таких маршрутов. В дополнение к сказанному, организации, на которые будет ложиться основная тяжесть решения этой задачи, будут разными для разных вариантов решения. Например, решения могут различаться по:

• ресурсам, используемым на маршрутизаторах внутри TRD;
• административным издержкам для персонала TRD;
• сложности настройки основанной на правилах междоменной маршрутизации в каждом краевом маршрутном домене.

Используемое решение может влиять на реальные маршруты, по которым будут передаваться пакеты, а также на доступность резервных маршрутов при возникновении отказов на основном пути.

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

6.3 Рекомендации по администрированию адресов IP

Связанный с данным документ [3] содержит рекомендации по администрированию адресов IP.

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

Авторы рады отметить существенный вклад в эту работу, сделанный авторами RFC 1237 [2] (Richard Colella, Ella Gardner и Ross Callon). Важные концепции (и значительные фрагменты текста) были непосредственно заимствованы из этого документа.

Авторы рады отметить важный вклад в работу членов групп Federal Engineering Planning Group (FEPG) и International Engineering Planning Group (IEPG). Данный документ также отражает концепции, высказанные на конференции IETF Addressing BOF (Cambridge, MA) в июле 1992 г.

Мы выражаем благодарность Peter Ford (Los Alamos National Laboratory), Elise Gerich (MERIT), Steve Kent (BBN), Barry Leiner (ADS), Jon Postel (ISI), Bernhard Stockman (NORDUNET/SUNET), Claudio Topolcic (CNRI) и Kannan Varadhan (OARnet) за их комментарии и обзор данного документа.

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

[1] Fuller, V., Li, T., Yu, J., and K. Varadhan, “Supernetting: an Address Assignment and Aggregation Strategy”, RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.

[2] Colella, R., Gardner, E, and R. Callon, “Guidelines for OSI NSAP Allocation in the Internet”, RFC 1237, JuNIST, Mitre, DEC, July 1991.

[3] Gerich, E., “Guidelines for Management of IP Address Space”, RFC 1466, Merit, May 1993.

[4] Cerf, V., “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet “Connected” Status”, RFC 1174, CNRI, August 1990.

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

В документе не обсуждаются какие-либо вопросы безопасности.

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

Yakov Rekhter

T.J. Watson Research Center, IBM Corporation

P.O. Box 218

Yorktown Heights, NY 10598

Phone: (914) 945-3896

EMail: yakov@watson.ibm.com

Tony Li

cisco Systems, Inc.

1525 O’Brien Drive

Menlo Park, CA 94025

EMail: tli@cisco.com

---

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

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

nmalykh@gmail.com