Network Working Group V. Fuller
Request for Comments: 1519 BARRNet
Obsoletes: 1338 T. Li
Category: Standards Track cisco
J. Yu
MERIT
K. Varadhan
OARnet
September 1993
Бесклассовая междоменная маршрутизация (CIDR)
Выделение адресов и стратегия агрегирования
Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
Статус документа
В данном RFC содержится спецификация стандарта, предложенного сообществу Internet; документ служит приглашением к дискуссии в целях совершенствования и развития данной спецификации. Информацию о текущем состоянии стандартизации для этого протокола вы можете найти в документе “Internet Official Protocol Standards”. Документ может распространяться без ограничений.
Тезисы
В документе обсуждается стратегия распределения существующего адресного пространства с точки зрения повышения эффективности его использования и вопросы предотвращения взрывного роста размеров таблиц маршрутизации в маршрутизаторах, не имеющих принятого по умолчанию маршрута.
Оглавление
Исключено в HTML-версиию
Благодарности
Авторы хотят выразить свою признательность участникам группы ROAD за использование в этом документе поданных ими идей.
1. Проблема, цели, мотивация
В последние годы сеть Internet развивается и растет, делая очевидными некоторые весьма серьезные проблемы масштабирования. К таким проблемам относятся:
-
Нехватка адресного пространства для сетей класса B. Одной из основных причин этого является отсутствие класса адресов, подходящего по числу адресов для организаций средних размеров. Сети класса C могут включать до 254 адресов (слишком мало), а сети класса B позволяют адресовать до 65534 хостов, что является явным избытком для организации средних размеров. В результате блоки адресов класса B используются неэффективно.
-
Избыток маршрутной информации. Размеры и скорость роста таблиц маршрутизации в маршрутизаторах Internet превосходят возможности существующих программ (и людей) по эффективному управлению этими таблицами.
-
Общая нехватка номеров IP для сетей.
Стало ясно, что две первых проблемы из этого списка уже в ближайшее время станут критическими. Бесклассовая междоменная маршрутизация CIDR1 является попыткой решения этих проблем путем определения механизма, который замедлит рост таблиц маршрутизации и снизит актуальность проблемы выделения номеров IP для новых сетей. Механизм не содержит способов решения третьей проблемы, которая не столь остра, но и ее актуальность снижается, обеспечивая возможность эффективного функционирования Internet до того, как будет найдено долговременное решение проблем.
Предлагаемое решение состоит в топологическом распределении выделяемых вновь адресов IP с выделением сегментов адресного пространства IP транзитным доменам маршрутизации.
Предлагаемый в документе план распределения адресов IP следует реализовать как можно скорее. Мы надеемся, что этого будет достаточно на период поиска и реализации долговременного решения перечисленных проблем. Этот план решит проблемы по крайней мере на ближайшие три (3) года, в течение которых должно быть найдено подходящее долгосрочное решение.
Предлагаемый план направлен прежде всего на решение первых двух проблем. Мы надеемся, что разумное использование методов деления на подсети переменных размеров снизит также остроту проблемы нехватки 32-битового адресного пространства. Отметим также, что эффективные инструменты распределения адресов в мире с supernet и подсетями переменного размера окажет существенную помощь пользователям в принятии этих (порой недостаточно понятных) методов. Сообществу Internet следует приложить усилия к разработке простых инструментов для такого распределения.
Отметим, что этот план не требует и не предполагает заново распределять уже выданные адреса, хотя по возможности это следует сделать в целях дополнительного снижения размеров таблиц маршрутизации. Предполагается, что технологии маршрутизации смогут обеспечить работу с таблицами существующих размеров и даже при незначительном росте размера таблиц маршрутизации. Задачей предлагаемого плана является существенное снижение скорости роста размеров таблиц маршрутизации.
Отметим, что этот план не требует смены адресов в доменах, которые меняют подключенные к ним транзитные домены. Одобряется такая переадресация внутри доменов маршрутизации, которая не будет требовать анонсирования отдельных блоков, выделенных внутри домена.
Этот план не будет оказывать влияния на реализацию любых специфических долгосрочных планов и, следовательно, в данном документе не обсуждаются какие-либо долгосрочные планы для архитектуры маршрутизации и адресации.
2. Распределение адресов CIDR
Описываемый план адресации и маршрутизации состоит из двух основных частей, одна из которых служит для распределения адресного пространства Internet, а вторая обеспечивает механизм агрегирования маршрутной информации.
2.1 Агрегирование и его ограничения
Одной из основных целей предлагаемого плана является такое распределение адресного пространства Internet, которое позволит агрегировать маршрутную информацию с учетом топологии. Для простых клиентов с одним интерфейсом выделение адресного пространства из блоков транзитных доменов маршрутизации будет автоматически обеспечивать возможность агрегирования. Вместо анонсирования отдельного маршрута к каждому из таких клиентов транзитный домен может анонсировать один агрегированный маршрут, описывающий все блоки адресов, подключенных к нему клиентов. К сожалению не все сайты имеют единственное подключение к сети и в таких нетривиальных случаях возможны сложности при агрегировании маршрутов.
Существуют две ситуации, в которых теряется эффективность агрегирования маршрутов.
-
Организации с множеством подключений. Поскольку многодомные сети должны анонсироваться в систему каждым из сервис-провайдеров, зачастую не удается агрегировать маршруты в такие сети в адресное пространство каждого из провайдеров. Отметим, что такие организации могут по-прежнему использовать адреса из пространства транзитных доменов (в этом есть определенные преимущества), но их маршрутная информация должна явно анонсироваться большинством их сервис-провайдеров (исключением является случай, когда блок адресов получен от провайдера, маршрут к которому наименее предпочтителен, – в таких случаях этот провайдер может не анонсировать маршрут явно, поскольку выбор по максимальной длине соответствия обеспечит доступ к сайту при анонсировании агрегированного маршрута). В силу перечисленных причин “стоимость” маршрута в такие сети практически не будет изменяться по сравнению с существующей.
-
Организации, меняющие сервис-провайдера без смены адресного блока. В таких случаях в агрегированном маршруте прежнего провайдера возникает пропуск2. Предлагаемый план для решения такой проблемы требует от нового провайдера анонсировать специфический маршрут к новому клиенту так, чтобы этот маршрут оказывался более предпочтительным за счет более длинного соответствия. Для обеспечения эффективности агрегирования организациям, планирующим смену сервис-провайдера, рекомендуется менять и блок адресов, получая его от нового провайдера. Для упрощения такого перехода рекомендуется разработать механизмы, включающие улучшенные протоколы и процедуры динамического выделения адресов.
Отметим, что некоторое повышение эффективности агрегирования может быть достигнуто и для многодомных сайтов (и, в общем случае, для любого сайта, содержащего множество логических сетей IP) за счет выделения клиенту непрерывного блока с количеством адресов, являющимся степенью числа 2 (вместо множества независимых адресных блоков). В этом случае маршрутная информация от клиента может быть агрегирована в одну пару адрес-маска. Кроме того, поскольку стоимость маршрута, связанного с выделением многодомному сайту блока адресов из пространства провайдера, не превышает стоимость маршрута при существующем выделении произвольных блоков регистрационными агентствами, имеет смысл во всех случаях выделять адресное пространство из провайдерских блоков.
Имеет смысл также отметить, что агрегирование может выполняться на разных уровнях системы, что делает возможным агрегирование таких аномальных маршрутов на более высоких уровнях иерархии. Например, если многодомный сайт подключен к двум региональным сетям NSFNET и обе сети используют адреса из пространства NSFNET, агрегирование маршрутов произойдет на уровне NSFNET.
Наконец, следует отметить, что реализацию нового плана адресации, описанная в документе можно (и следует) начинать незамедлительно, но эффективное использование этого плана для агрегирования маршрутов будет требовать внесение изменений в некоторые протоколы междоменной маршрутизации. Более того, реализация протоколов бесклассовой междоменной маршрутизации без реализации нового плана распределения адресов не позволит обеспечить эффективное агрегирование маршрутов (иными словами, требуется изменить план распределения адресов и протоколы маршрутизации требуются для того, чтобы можно было эффективно объединять маршруты и замедлить рост таблиц маршрутизации). Отметим, однако, что в период между реализацией нового плана распределения адресов и развертыванием новых протоколов маршрутизации размер таблиц может начать увеличиваться очень быстро. Это следует принимать во внимание при рассмотрении вопросов реализации планов.
Примечание. В документе при обсуждении и в примерах используется нотация в форме сетей и масок для представления адресатов в маршрутах. Такое обозначение принято для наглядности и не требуется использовать такую же нотацию в обновлениях, передаваемых протоколами маршрутизации.
2.2 Распределенное выделение адресов
Основная идея плана состоит в выделении каждому сервис-провайдеру одного или множества адресных блоков класса C. Организации, использующие провайдеров для подключения к Internet, получают задаваемые битовыми масками подсети из адресного пространства провайдера.
Следует также отметить, что по мере распространения протоколов бесклассовой междоменной маршрутизации описанные в этом плане правила могут быть использованы для выделения объединения (supernetting) или разбиения на подсети оставшегося свободным адресного пространства классов A и B (в предположении, что бесклассовая междоменная маршрутизация будет допускать существование в системе подсетей, не являющихся непрерывными, или все компоненты одного блока класса A или B будут содержаться в одной домене маршрутизации). Это позволит использовать описываемый план даже в том случае, когда свободные блоки адресов класса C закончатся раньше, нежели будет реализовано долгосрочное решение. Такой вариант более подробно рассматривается в главе 6.
Иерархическое распределение адресов в такой манере предполагает, что клиенты с адресами из провайдерского блока с точки зрения маршрутизации являются частью сети данного провайдера и маршрутизация к таким клиентам обеспечивается провайдером. Такой подход предполагает, что маршрутные данные о многодомных сайтах (т. е., организациях, подключенных к сетям нескольких провайдеров) должны быть известны вышележащим уровням иерархии.
Преимуществами иерархического распределения адресов перечислены ниже.
-
Ожидается, что будет проще централизованно выделять адреса сравнительно небольшому числу сервис-провайдеров, нежели значительно большему и постоянно растущему числу отдельных клиентов. Это не будет рассматриваться как потеря части адресного пространства сервис-провайдеров.
-
С учетом постоянного роста Internet это обеспечивает масштабируемый способ распределения адресов с возможностью передачи полномочий по выделению адресов другим агентствам.
В силу сказанного выше и в интересах обеспечения согласованной процедуры получения адресов Internet рекомендуется большую часть (если не все) адресов распределять через сервис-провайдеров. Более подробное обсуждение этих вопросов вы найдете в документе [2].
3. Анализ преимуществ
Новый метод распределения адресов через сервис-провайдеров можно использовать незамедлительно и он сразу же будет обеспечивать преимущества в результате распределения централизованных функций выделения новых адресов. К сожалению преимущества для достижения преимуществ от снижения размеров глобально распространяемых таблиц маршрутизации могут быть достигнуты только после развертывания протоколов бесклассовой междоменной маршрутизации, способных работать с произвольными парами адрес-маска. Только в этом случае станет возможным агрегирование отдельных сетей класса C в более крупные блоки, представляемые в таблице маршрутизации одной записью.
Это означает, что новый план сам по себе не сможет оказать влияния на рост размеров таблиц маршрутизации. Однако после развертывания новых протоколов междоменной маршрутизации начнется незамедлительное снижение числа записей для новых адресатов, которые должны будут передаваться протоколами маршрутизации. Детальный анализ этого процесса и перманентного снижения скорости роста размеров таблиц маршрутизации дается в следующей главе.
Следует также отметить что существующий “плоский” метод централизованного распределения адресов связан со значительными бюрократическими издержками в агентстве по распределению. Для повышения эффективности процесса распределения адресов (безотносительно к их нехватке или переполнению таблиц маршрутизации) механизм распределения следует изменить. Использование предложенного в этом документе механизма будет иметь также позитивный побочный эффект – за счет распределения функций выделения адресов существенно снизится загрузка центрального агентства.
3.1 Существующая картина распределения
Неформальный анализ “network-contacts.txt” (файл доступен через DDN NIC) показывает, что на 2 февраля 1992 г было распределено 46 сетей класса A из 126 возможных (свободен 81 блок) и 5467 из 16382 возможных блоков класса B (свободно 10915). В предположении, что тенденции распределения адресов будут сохраняться, число выделяемых блоков класса B будет удваиваться приблизительно за год. При таком росте скорости все сети класса B будут распределены в течение примерно 15 месяцев. На 13 января 1993 г. были распределены 52 сети класса A и 7133 сети класса B. Мы предполагаем, что изменение скорости распределения блоков класса B обусловлено началом реализации рассматриваемого здесь плана.
3.2 История роста размеров таблиц
Таблица 1: Рост размера анонсируемых таблиц маршрутизации
| Дата | Число записей | Дата | Число записей | Дата | Число записей |
|---|---|---|---|---|---|
|
декабрь, 1992 |
8561 |
июнь, 1991 |
2982 |
декабрь, 1989 |
897 |
|
ноябрь, 1992 |
7854 |
май, 1991 |
2763 |
ноябрь, 1989 |
837 |
|
октябрь, 1992 |
7354 |
апрель, 1991 |
2622 |
октябрь, 1989 |
809 |
|
сентябрь, 1992 |
6640 |
март, 1991 |
2501 |
сентябрь, 1989 |
745 |
|
август, 1992 |
6385 |
февраль, 1991 |
2417 |
август, 1989 |
650 |
|
июль, 1992 |
6031 |
январь, 1991 |
2338 |
июль, 1989 |
603 |
|
июнь, 1992 |
5739 |
декабрь, 1990 |
2190 |
июнь, 1989 |
564 |
|
май, 1992 |
5515 |
ноябрь, 1990 |
2125 |
май, 1989 |
516 |
|
апрель, 1992 |
5291 |
октябрь, 1990 |
2063 |
апрель, 1989 |
467 |
|
март, 1992 |
4976 |
сентябрь, 1990 |
1988 |
март, 1989 |
410 |
|
февраль, 1992 |
4740 |
август, 1990 |
1894 |
февраль, 1989 |
384 |
|
январь, 1992 |
4526 |
июль, 1990 |
1727 |
январь, 1989 |
346 |
|
декабрь, 1991 |
4305 |
июнь, 1990 |
1639 |
декабрь, 1988 |
334 |
|
ноябрь, 1991 |
3751 |
май, 1990 |
1580 |
ноябрь, 1988 |
313 |
|
октябрь, 1991 |
3556 |
апрель, 1990 |
1525 |
октябрь, 1988 |
291 |
|
сентябрь, 1991 |
3389 |
март, 1990 |
1038 |
сентябрь, 1988 |
244 |
|
август, 1991 |
3258 |
февраль, 1990 |
997 |
август, 1988 |
217 |
|
июль, 1991 |
3086 |
январь, 1990 |
927 |
июль, 1988 |
173 |
В таблице 1 приведены данные MERIT.
3.3 Детальный анализ
Существуют незначительные издержки технического и административного типа, связанные с реализацией нового плана распределения адресов. Административные издержки связаны с убеждением NIC, IANA и сервис-провайдеров с необходимостью реализации этого плана – эта задача не представляется сложной. Важно что при реализации этого плана существенно сокращаются издержки на централизованное (NIC и IANA) распределение адресов. Однако для получения преимуществ в результате агрегирования маршрутной информации требуется возможность представления маршрутов в форме номеров сетей и масок произвольного размера (в отличие от фиксированных размеров номеров сетей и масок для классов A/B/C). Поддержка адресов и масок нефиксированных размеров должна быть добавлена в используемые протоколы междоменной маршрутизации. Таким образом, издержки технического характера заключаются в реализации протоколов бесклассовой междоменной маршрутизации.
3.3.1 Преимущества нового плана адресации
Реализация плана обеспечивает два преимущества:
-
существующая проблема нехватки адресов класса B может быть решена выделением подходящего числа блоков класса C организациям средних размеров (200 – 4000 хостов);
-
после развертывания переработанных протоколов междоменной маршрутизации произойдет незамедлительное снижение числа записей в таблицах маршрутизации, а впоследствии скорость роста таблиц (для маршрутизаторов, не использующих принятого по умолчанию пути) существенно снизится по сравнению с текущей скоростью их роста.
3.3.2 Оценка скорости роста размеров таблиц
В январе 1992 г. размер таблиц а маршрутизаторах, не использующих принятого по умолчанию пути (например, в магистральных маршрутизаторах NSFNET) составлял приблизительно 4700 записей. Это значение отражает текущий размер маршрутной базы данных NSFNET. Просмотр статистики роста размеров таблиц показывает, что в среднем за период между 1988 и 1991 годом этот размер удваивался каждые 10 месяцев. Если предположить, что такая скорость сохранится (нет основания для иных предположений), можно ожидать, что за два года размер таблиц в маршрутизаторах, не использующих принятого по умолчанию маршрута, возрастет до 30000. В приведенном далее анализе предполагается, что экспоненциальное расширение Internet будет сохраняться.
Следует отметить, что в этих оценках не принимался во внимание тот факт, что в силу нехватки адресов класса B, многие организации могут получать взамен множество блоков класса C. Предполагая, что компании средних размеров, которым раньше выдавались блоки класса B будут получать от 4 до 16 сетей класса C, мы видим, что скорость роста размеров таблиц маршрутизации может увеличиться вдвое или даже в 4 раза. Это означает, что число записей в маршрутизаторах, не использующих принятого по умолчанию пути, может превысить 10 000 в течение шести месяцев и 20 000 менее, чем за год.
В декабре 1992 размер таблицы маршрутизации составлял 8500 записей, хотя по прогнозам в таблицах должно было содержаться уже 9400 маршрутов. В настоящий момент еще неясно, можно ли говорить о существенно изменении скорости роста размеров таблиц.
При реализации предложенного плана скорость роста таблиц в маршрутизаторах без принятого по умолчанию маршрута сильно замедляется, поскольку большая часть выделяемых вновь адресов будет относиться к одному из больших блоков, выделенных сервис-провайдерам. Для упрощения анализа будем предполагать скорую реализацию плана и развертывание обновленных протоколов маршрутизации. Будем предполагать также, что выделенных изначально провайдерам блоков адресов хватит на два ближайших года.
Поскольку в соответствии с этим планом многодомные сети должны по-прежнему явно анонсировать себя через систему (согласно правилу #1, описанному в параграфе 4.2), предполагается, что число маршрутов из таких сетей будет основным фактором роста таблиц маршрутизации после того, как будет реализован план агрегирования маршрутов (supernetting).
По текущим оценкам число многодомных организаций, подключенных к Internet, менее 100. Каждая из таких организаций использует один или несколько номеров сетей. Во многих случаях (после реализации этого плана – во всех) номера сетей организации идут последовательно, что позволяет агрегировать эти сети при анонсировании маршрутов. Это означает, что число маршрутов, анонсируемых в Internet для многодомных сетей может быть приблизительно равным числу многодомных организаций. В предположении, что количество многодомных организаций будет удваиваться каждый год (эта оценка может оказаться преувеличенной, поскольку каждое подключение стоит денег), число маршрутов для многодомных сетей вырастет за три года приблизительно до 800.
Предположим далее, что существует около 100 сервис-провайдеров и каждому из них также требуется анонсировать свой блок адресов. Однако в результате агрегирования такое анонсирование будет создавать только 100 дополнительных маршрутов. Будем предполагать, что по истечении двух первых лет новые сервис-провайдеры вкупе с новыми блоками существующих провайдеров будут добавлять 50 маршрутов в год. Таким образом, суммарное число маршрутов составит 4700 + 800 + 150 = 5650. Это дает годовой прирост около 6%, что во много раз меньше нынешнего роста в 130%. В этом анализе предполагается незамедлительная реализация предлагаемого плана с полным соответствием документу. Отметим, что при анализе принимался во внимание только один уровень агрегирования маршрутов в сети Internet – разумное выделение адресов позволит использовать многоуровневое агрегирование.
Очевидно, что прогнозы не могут оказаться точными на 100%, равно как не следует ожидать незамедлительной и полной реализации предложенного плана. Однако при выполнении этого плана 90% сервис-провайдеров приведет к тому, что в течении трех лет размер таблиц маршрутизации достигнет 4700 + 800 + 145 + 7500 = 13145, тогда как существующие темпы прироста приведут за такое же время к росту таблиц приблизительно до 75000 маршрутов.
4. Изменения протоколов и практики междоменной маршрутизации
Очевидно, что для эффективной поддержки supernet потребуется изменение протоколов маршрутизации и способов интерпретации маршрутной информации. Для “новых” протоколов междоменной маршрутизации изменения синтаксиса должны быть сравнительно невелики. Этот механизм не будет работать со старыми протоколами междоменной маршрутизации типа EGP2 – для обеспечения интероперабельности со старыми системами, использующими такие протоколы, следует обратиться к механизмам обеспечения принятого по умолчанию маршрута или требовать, чтобы новые маршрутизаторы при обмене информацией со старыми разбивали агрегированные маршруты по номерам отдельных сетей. Поскольку первый вариант является тривиальным, а второй слишком громоздким (значительный расход памяти на разделение агрегированных маршрутов), рекомендуется использовать первый вариант – тогда старые системы смогут по-прежнему использовать механизм принятого по умолчанию маршрута.
Отметим, что настоящий план предполагает использование в организациях, которым требуется импортировать supernet-информацию в свою систему маршрутизации, должны использовать протоколы IGP, поддерживающие бесклассовые маршруты (например, OSPF [1]). Системы, использующие старые протоколы IGP, могут по-прежнему анонсировать и получать supernet-информацию, но они не способны распространять такую информацию через свои домены маршрутизации.
4.1 Изменения семантики
Для реализации рассматриваемого здесь плана нужно внести два фундаментальных изменения в протоколы междоменной маршрутизации. Первое изменение заключается в отказе от использования “классов сетей” – данный план предполагает что адресаты маршрута представляются парами “номер сети – маска” и выбор маршрута осуществляется по максимальной длине соответствия (т. е., для конкретного адресата может существовать множество подходящих пар “номер сети – маска”, из которых выбирается с большим размером маски). Современные протоколы маршрутизации в основном не поддерживают концепцию агрегирования маршрутов и второе изменение состоит в реализации новой семантики с поддержкой агрегирования в протоколах междоменной маршрутизации. При агрегировании маршрутов для многодомных сайтов или сайтов, которые сменили своего провайдера могут возникать дополнительные сложности. К счастью для таких случаев можно определить несколько достаточно простых правил.
4.2. Правила анонсирования маршрутов
-
Маршрутизация ко всем адресатам должна осуществляться только с использованием пути с максимальной длиной соответствия. Это подразумевает, что адресаты, являющиеся многодомными, всегда явно анонсируются в домен маршрутизации. Такие маршруты нельзя объединять с другими – интуитивно понятно, что для многодомной сети все ее пути в домен маршрутизации, расположенный выше в сетевой иерархии, должны быть известны в расположенной иерархически выше сети.
-
Домен маршрутизации, объединяющий множество маршрутов в один, должен отбрасывать пакеты, которое соответствуют агрегированному маршруту, но не соответствуют ни одному из явных маршрутов, использованных при создании агрегированного маршрута. Это важно для предотвращения петель в маршрутизации при наличии менее специфичной информации (например, принятого по умолчанию маршрута). Разработчикам следует иметь в виду, что одним из простых способов реализации этого правила будет поддержка на граничных маршрутизаторах “нисходящего” маршрута в каждую из используемых при агрегировании сетей. При использовании правила выбора маршрута по максимальной длине совпадения, весь трафик, адресованный получателям, к которым не известно явного пути, будет отбрасываться.
Отметим, что во время отказов в сети, могут происходить частичные нарушения маршрутизации для сайтов, которые берут блок адресов от одного сервис-провайдера, а реально доступны через другого (это сайты, сменившие провайдера без замены блока адресов). Правило 2 будет предотвращать возникновение реальных проблем, вынуждая отбрасывать такой трафик маршрутизатором, анонсирующим агрегированный маршрут, но вывод программы traceroute и других инструментов такого типа будет показывать наличие проблем в сети провайдера, анонсирующего агрегированный маршрут. Это может вводить в заблуждение (см. пример в параграфе 5.2). Решение этой проблемы для протоколов междоменной маршрутизации, существующих на момент создания этого плана, не представляется возможным. Проблема должна быть решена при создании новых протоколов маршрутизации.
Приведенные ниже рекомендации позволяют обобщить эти правила для того, чтобы можно было воспринимать произвольные пары номер-маска для всех адресатов. Единственным ограничением остается требование к непрерывности битов маски. Отметим, что для принятого по умолчанию маршрута используется вырожденная пара адрес-маска (0.0.0.0, 0.0.0.0), которая должна восприниматься всеми реализациями. Для предотвращения случайного анонсирования этого маршрута через протокол междоменной маршрутизации, такой маршрут никогда не должен анонсироваться, если конкретная конфигурация не задает необходимость таких анонсов.
Системы, обрабатывающие анонсы маршрутов, должны быть способны проверить корректность полученной информации. Таким образом, реализация данного плана, которая фильтрует анонсы маршрутов, должна также поддерживать маски в элементах фильтра. Чтобы упростить администрирование будет полезно в элементах фильтрации автоматически разрешать более специфичные адреса и маски. Таким образом, набор фильтров вида
accept 128.32.0.0 accept 128.120.0.0 accept 134.139.0.0 deny 36.2.0.0 accept 36.0.0.0
будет работать как фильтры
accept 128.32.0.0 255.255.0.0 accept 128.120.0.0 255.255.0.0 accept 134.139.0.0 255.255.0.0 deny 36.2.0.0 255.255.0.0 accept 36.0.0.0 255.0.0.0
Это просто делает явными маски сетей, которые неявно предполагались для сетей классов A/B/C.
4.3. Как работают правила
Правило 1 гарантирует совместимость алгоритма маршрутизации в разных реализациях и совместимость с другими протоколами маршрутизации (такими, как OSPF). Многодомные сети всегда анонсируются явно каждым сервис-провайдером, через которого они маршрутизируются даже если такие сети являются частью агрегированного маршрута сервис-провайдера. Может казаться, что “основной” провайдер может неявно анонсировать многодомную сеть (как часть агрегированного маршрута), однако правило выбора маршрута по наибольшей длине соответствия приведет к тому, что работать это не будет.
Правило 2 гарантирует, что в результате агрегирования маршрутов не образуется маршрутных петель. Рассмотрим сеть среднего уровня, которой выделено 2048 блоков адресов класса C, начиная с номера 192.24.0.0 (см. также пример в главе 5). Средний уровень передает в “магистраль” свои анонсы 192.24.0.0/255.248.0.0. Предположим, что для “магистральной” сети выделен блок адресов 192.0.0.0/255.0.0.0. Эта сеть тогда будет анонсировать на средний уровень агрегированный маршрут для этого блока. В таком случае, если сеть среднего уровня утратит внутреннюю связность с сетью 192.24.1.0/255.255.255.0 (часть агрегированного маршрута), трафик из “магистрали”, адресованный хосту 192.24.1.1, будет соответствовать анонсируемому средним уровнем маршруту. Когда такой трафик попадет на средний уровень, эта сеть не должна анонсу 192.0.0.0/255.0.0.0, полученному из “магистральной” сети, поскольку это будет приводить к возникновению петли в маршрутизации. Правило 2 говорит, что для среднего уровня недопустимо использовать менее специфичный маршрут, который соответствует одному из агрегируемых этой сетью маршрутов. Отметим, что обработка “маршрута по умолчанию” (0.0.0.0/0.0.0.0) является специальным случаем этого правила – сеть не должна использовать принятый по умолчанию путь для адресатов, которые являются частью анонсируемого этой сетью агрегированного маршрута.
4.4. Ответственность за настройку агрегирования
Домен, которому выделен диапазон адресов, имеет исключительное право на агрегирование маршрутов для своего адресного пространства. В обычном случае автономная система (AS) будет использовать на граничных маршрутизаторах конфигурационные команды для агрегирования некоторой части своего адресного пространства. Домен может также передать (делегировать) полномочия агрегирования маршрутов в другой домен. В этом случае агрегирование будет осуществляться другим доменом на одном из его граничных маршрутизаторов.
Когда маршрутизатор на границе между доменами агрегирует маршруты, ему нужно знать диапазон адресов IP, для которых объединяются маршруты. Основным принципом объединения является агрегирование как можно большего числа маршрутов без включения в объединенный маршрут тех блоков, которые не могут трактоваться как часть блока адресов ввиду наличия многодомных сайтов, принятой политики и пр.
Одним из механизмов является агрегирование, основанное только на динамической маршрутной информации. Такой способ связан с риском неточного указания диапазона при отсутствии того или иного маршрута и не всегда возможно отличить временную недоступность от случаев, когда маршрут более не должен включаться в агрегирование. Полностью динамическая система маршрутизации также не обеспечивает возможности точного определения маршрутов для агрегирования. Другой механизм основан на задании агрегируемых блоков в параметрах конфигурации маршрутизатора. Этот метод является предпочтительным в силу большей гибкости и возможности точного задания диапазона агрегируемых адресных блоков.
Настройка конфигурации требует участия администратора, но эта работа не превышает нагрузку на администраторов сегодняшних маршрутизаторов. Администратору достаточно просто добавить одну или две строки, определяющих блок адресов IP для агрегирования маршрутов. Если маршрутизатор агрегирует маршруты, его администратор знает диапазон адресов, выделенных для домена. Если принимающий домен уполномочен агрегировать маршруты и выполняет эту операцию, администратор этого домена также знает диапазон адресов для агрегирования, поскольку этот диапазон указывается при передаче полномочий на агрегирование маршрутной информации. Поскольку администратору известно какие маршруты следует агрегировать, настройка конфигурации для выполнения таких действий не создает большой нагрузки для администратора.
Примечание для разработчиков: агрегирование маршрутов для адресов класса D (групповая адресация) в настоящее время не изучено. Не следует агрегировать такие маршруты, даже если это возможно.
4.5 Рассмотрение протоколов внутридоменной маршрутизации
Хотя для поддержки анонсирования агрегированных маршрутов не требуется поддержка таких функций от протоколов внутренней маршрутизации, достаточно часто встречаются ситуации, когда внешняя маршрутная информация передается протоколами внутренней маршрутизации в соответствии с принятой политикой или при передаче такой информации через транзитную сеть. С момента появления агрегированных маршрутных данных в новых протоколах внешней маршрутизации практику импорта внешних маршрутных данных придется изменять. Транзитные сети, импортирующие внешнюю информацию, должны будут использовать тот или иной из перечисленных вариантов:
-
использовать протокол внутренней маршрутизации, поддерживающий агрегирование маршрутов;
-
найти иной способ распространения внешней информации, который не будет использовать ее лавинной рассылки с использованием протокола внутренней маршрутизации (например, использовать в качестве внутреннего протокол BGP);
-
прекратить импорт внешней информации и использовать лавинную рассылку принятого по умолчанию маршрута через внутренний протокол для определения путей к внешним адресатам.
В случае (a) требуется изменение протокола маршрутизации для поддержки агрегированных маршрутов, что может оказаться достаточно сложной задачей. Протоколы типа OSPF и IS-IS, которые представляют маршрутную информацию в форме адрес-маска (OSPF) или префикс-размер префикса (IS-IS) поддержку агрегированной информации организовать достаточно просто, однако для протоколов, работа которых основана на использовании классов сетей, или протоколов, которые могут работать только с подсетями фиксированных размеров, потребуются более фундаментальные изменения. Но даже в концептуально простых случаях OSPF и IS-IS, требуется вносить изменения в реализации протокола для поддержки supernet в базе данных или таблице пересылки.
5. Примеры нового распределения и маршрутизации
5.1 Выделение адресов
Рассмотрим блок из 2048 адресов класса C, начинающийся с сети 192.24.0.0 (0xC0180000 и заканчивающийся сетью 192.31.255.0 (0xC01FFF00), который выделен одному провайдеру (RA). Агрегированный маршрут к этому блоку адресов будет описываться как 192.24.0.0 с маской 255.248.0.0 (0xFFF80000). Предположим, что к сервис-провайдеру подключено шесть клиентов в показанном ниже порядке (порядок важен для демонстрации возникновения временных “дыр” в адресном пространстве провайдера):
C1 требуется менее 2048 адресов (8 сетей класса C)
C2 требуется менее 4096 адресов (16 сетей класса C)
C3 требуется менее 1024 адресов (4 сети класса C)
C4 требуется менее 1024 адресов (4 сети класса C)
C5 требуется менее 512 адресов (2 сети класса C)
C6 требуется менее 512 адресов (2 сети класса C)
Во всех случаях число адресов IP, запрошенных каждым клиентом, предполагает возможность значительного роста. Провайдер выделил клиентам следующие блоки адресов:
C1: блок 192.24.0 – 192.24.7, описываемый агрегированным маршрутом 192.24.0.0 с маской 255.255.248.0
C2: блок 192.24.16 – 192.24.31, описываемый маршрутом 192.24.16.0 с маской 255.255.240.0
C3: блок 192.24.8 – 192.24.11, описываемый маршрутом 192.24.8.0 с маской 255.255.252.0
C4: блок 192.24.12 – 192.24.15, описываемый маршрутом 192.24.12.0 с маской 255.255.252.0
C5: блок 192.24.32 – 192.24.33, описываемый маршрутом 192.24.32.0 с маской 255.255.254.0
C6: блок 192.24.34 – 192.24.35, описываемый маршрутом 192.24.34.0 с маской 255.255.254.0
Отметим, что при использовании провайдером протокола IGP, который может поддерживать бесклассовые сети, этот провайдер может (но не обязан) объединять блоки (supernet) в точке подключения клиента и, следовательно, поддерживать всего 6 маршрутов для 36 выделенных клиентам блоков класса C. Если объединение маршрутов не поддерживается, все 36 блоков будут передаваться протоколом IGP.
Чтобы сделать наш пример более реалистичным, предположим, что C4 и C5 являются многодомными и подключены также к другому провайдеру (RB). Дополнительно предположим существование клиента C7, который изначально был подключен к провайдеру RB, а потом перешел к RA. Этот клиент использует адреса из блока провайдера RB (следующие 2048 сетей класса C):
C7: блок 192.32.0 – 192.32.15, описываемый маршрутом 192.32.0 с маской 255.255.240.0
Для многодомных клиентов предположим, что C4 анонсирует RA как основного провайдера, а RB – как вспомогательного; для C5 основным является RB, а вторичным RA. Для того, чтобы собрать все воедино, предположим, что провайдеры RA и RB соединены между собой через “магистрального” провайдера BB.
На приведенном ниже рисунке представлена схема соединений:
C1 192.24.0.0 -- 192.24.7.0 \ _ 192.32.0.0 - 192.32.15.0 192.24.0.0/255.255.248.0 \ / 192.32.0.0/255.255.240.0 \ / C7 C2 +----+ +----+ 192.24.16.0 - 192.24.31.0 \| | | | 192.24.16.0/255.255.240.0 | | _ 192.24.12.0 - 192.24.15.0 _ | | | | / 192.24.12.0/255.255.252.0 \ | | C3 -| |/ C4 \| | 192.24.8.0 - 192.24.11.0 | RA | | RB | 192.24.8.0/255.255.252.0 | |___ 192.24.32.0 - 192.24.33.0 ___| | /| | 192.24.32.0/255.255.254.0 | | C6 | | C5 | | 192.24.34.0 - 192.24.35.0 | | | | 192.24.34.0/255.255.254.0 | | | | +----+ +----+ \\ \\ 192.24.12.0/255.255.252.0 (C4) || 192.24.12.0/255.255.252.0 (C4) || 192.32.0.0/255.255.240.0 (C7) || 192.24.32.0/255.255.254.0 (C5) || 192.24.0.0/255.248.0.0 (RA) || 192.32.0.0/255.248.0.0 (RB) || || || VV VV +---------- BACKBONE PEER BB ----------+
5.2 Анонсирование маршрутов
В соответствии с правилом 1 провайдер RA должен анонсировать свой блок адресов и C7. Поскольку сеть C4 является многодомной и имеет основное подключение через RA, эта сеть также должна анонсироваться. Многодомная сеть C5 имеет основное подключение через RB. Эту сеть не нужно анонсировать, поскольку при выборе маршрута по максимальной длине соответствия магистраль BB будет автоматически выбирать маршрут через RB, а анонсируемый RA агрегированный маршрута будут использоваться как вторичный.
Анонсы из RA в BB будут иметь вид:
192.24.12.0/255.255.252.0 primary (advertises C4) 192.32.0.0/255.255.240.0 primary (advertises C7) 192.24.0.0/255.248.0.0 primary (advertises remainder of RA)
Для провайдера RB анонс должен включать C4 и C5, а также блок адресов провайдера RB. Более того, RB может анонсировать C7 как недоступную сеть.
Анонсы из RB в BB будут иметь вид:
192.24.12.0/255.255.252.0 secondary (advertises C4) 192.24.32.0/255.255.254.0 primary (advertises C5) 192.32.0.0/255.248.0.0 primary (advertises remainder of RB)
Для иллюстрации проблемы с “дырой”, упомянутой в параграфе 4.2, рассмотрим ситуацию, когда RA теряет соединение с C7 (клиент, использующий адреса из блока провайдера RB). В протоколе, поддерживающем информацию о состоянии соединений ((stateful protocol) RA будет анонсировать в BB недоступность блока 192.32.0.0/255.255.240.0. После того, как BB исключит этот маршрут их своей таблицы маршрутизации, любой трафик, передаваемый через BB в адрес недоступной сети, будет пересылаться провайдеру RB (где он будет отбрасываться согласно правилу 2), поскольку для RB получается максимальная длина соответствия 192.32.0.0/255.248.0.0. Хотя дополнительных проблем не возникает (сеть C7 все равно недоступна), в таких случаях может передаваться избыточный трафик через BB, а также могут быть введены в заблуждение администраторы, пытающиеся проверить путь в недоступную сеть с помощью traceroute. Здесь помог бы механизм кэширования информации о недоступности сети, но рассмотрение таких механизмов не входит в задачи данного документа и не очевидна возможность реализации подобного механизма в ближайшем будущем.
6. Расширение CIDR для адресов класса A
Несложно догадаться, что реализация этого плана в какой-то момент приведет к полному исчерпанию адресных блоков класса C. На момент подготовки документа верхняя половина адресного пространства класса A уже была зарезервирована для будущих расширений. В этой главе описано, как можно расширить действие плана CIDR для эффективного использования зарезервированного пространства класса A. Предполагается, что такая возможность будет использована только в том случае, если к моменту полного использования адресного пространства класса C не будет предложено долговременного решения.
Имеется два существенных различия в использовании адресов класса A и класса C. Первое различие заключается в том, что при делении на подсети блоков класса A несколько усложняется конфигурация DNS. Второе отличие состоит в том, что маршрутизаторы сетей класса A должны будут поддерживать бесклассовые протоколы IGP.
Поддержка DNS с разделенными на подсети блоками класса A является достаточно тяжелой задачей. Как часть механизма обратного преобразования адресов DNS поддерживает реверсный домен IN-ADDR.ARPA. Этот псевдо-домен содержит записи с обратным порядком байтовых полей IP-адресов и суффиксом IN-ADDR.ARPA и используется для определения имен хостов по их IP-адресам. Например, для хоста с адресом 131.108.1.111 в DNS имеется запись 111.1.108.131.IN-ADDR.ARPA. Поскольку псевдо-домены могут делегироваться только по границам байтов, это создает проблемы в тех случаях, когда конечный домен получает адресов, не выровненный по границе байта. Решение проблемы для таких случаев состоит в перечислении всех возможных комбинаций. Такой подход требует выполнения большой работы, но решает проблему. Более подробно это решение рассматривается ниже.
Маршрутизация в сети класса A с использованием CIDR также порождает интересную проблему. Обычно домен будет получать часть адресного пространства класса A. Такой домен может использовать протокол IGP, который поддерживает подсети переменного размера, или применять общую маску для всех хостов домена. В последнем случае возникают сложности, связанные с тем, что другие домены получившие адреса из того же блока A могут использовать отличающиеся маски. Если домен сам по себе является транзитным, ему может потребоваться выделение части полученных адресов для своих клиентов, которые также могут использовать отличающиеся маски. В этом случае клиентам потребуется информация об остальной части адресного блока класса A.
Если протокол IGP у клиента не поддерживает маски переменной длины, вопрос может быть решен путем анонсирования оставшейся части адресного блока класса A в виде подсетей подходящего размера. Однако в тех случаях, когда клиенты используют небольшие блоки, это приводит к необходимости организации большого числа подсетей (например, маска 255.255.255.0 будет требовать использования 65535 подсетей, включая сеть самого клиента). В силу этого может оказаться более разумным использовать в клиентском домене протокол IGP, поддерживающий подсети переменного размера.
Аналогичная ситуация наблюдается и для транзитных доменов. Очевидно, что такой домен не получит все пространство блока класса A и адреса из этого же блока будут выделены другим транзитным доменам. В этом случае транзитный домен также будет добавлять маршрутную информацию об остальной части адресного пространства блока класса A в протокол IGP. Ситуация аналогична описанной выше и связана с такими же сложностями. По этой причине рекомендуется использовать блоки класса A для CIDR только в тех случаях, когда во всем блоке используются протоколы IGP, поддерживающие подсети переменных размеров. Отметим, что от протоколов IGP не требуется поддержка supernet, как было сказано выше.
Отметим, что описанные здесь методы могут также применяться к адресам класса B. Однако ограниченное число свободных блоков класса B и их использование для многодомных сетей позволяю предположить, что оставшиеся блоки лучше зарезервировать для крупных организаций, которым нужен именно этот тип адресов [2].
7. Вопросы, связанные с серверами DNS
Одним из аспектов работы Internet, на который оказывает значительное влияние объединение (supernet) блоков класса C и разделение на подсети блоков класса AЮ является механизм определения имени хоста по его адресу – зона IN-ADDR.ARPA в системе доменных имен. Поскольку эта зона делегируется только по границе октетов, любой план распределения адресов, который использует маски переменной длины, будет порождать те или иные проблемы с поддержкой отдельных частей зоны IN-ADDR.ARPA.
7.1 Процедурные изменения для supernet класса C
В настоящее время части зоны IN-ADDR.ARPA делегируются только сетям, границы которых совпадают с границами полных октетов адреса. Для эффективного использования произвольных блоков адресов класса C рекомендуется отказаться от этого правила и позволить делегирование произвольных, ориентированных на октеты, частей зоны IN-ADDR.ARPA.
Как пример изменения правил рассмотрим гипотетическую крупную сеть провайдера BigNet, которая включает 1024 сети класса C с номерами от 199.0.0 до 199.3.255. В рамках действующих правил корневые серверы домена должны поддерживать 1024 записи вида:
0.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 1.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET. .... 255.3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
Изменив политику в соответствии с приведенными выше соображениями, можно снизить число записей в корневых серверах до 4:
0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 1.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 2.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
Провайдер может передать полномочия по поддержке частей зоны в отдельные сети класса C, которые были выделены клиентам, взамен поддержки таких зон у провайдера. Отметим, что устройство системы DNS позволяет корневым серверам поддерживать информацию о передаче полномочий для отдельных сетей, для которых провайдер не хочет или не может поддерживать сделать этого у себя. Такое решение существенно снижает нагрузку на серверы имен для “верхних” уровней зоны IN-ADDR.ARPA. Приведенный выше пример показывает только записи для одного сервера имен. В обычной ситуации для каждого домена существует несколько серверов имен и приведенные размеры могут удваиваться и утраиваться.
7.2 Процедурные изменения для подсетей в блоках класса A
При разбиении блоков класса A на подсети, выделяемые транзитным сервис-провайдерам, требуется отменить соответствующие ограничения и на делегирование частей домена IN-ADDR.ARPA для таких подсетей. В качестве примера рассмотрим провайдера, получившего 19-битовую часть адресного блока, которой соответствует номер 10.8.0.0 с маской 255.248.0.0. Это представляет все адреса, которые начинаются префиксами 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15 и требует следующих записей IN-ADDR.ARPA:
8.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET. 9.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET. .... 15.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
Для того, чтобы показать как работает дальнейшее делегирование IN-ADDR.ARPA, рассмотрим компанию FOO, подключенную к этому провайдеру и получившему 14-битовую часть адресного блока, которая соответствует номеру 10.10.64.0 с маской 255.255.192.0. Это представляет все адреса в диапазоне от 10.10.64.0 до 10.10.127.255 и будет требовать, чтобы провайдер обеспечил делегирование для фрагментов зоны IN-ADDR.ARPA
64.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM. 65.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM. .... 127.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
с серверами для FOO.COM, содержащими отдельные записи PTR для всех адресов в каждой из этих подсетей.
8. Переход к долговременному решению
Это решение не меняет архитектуры маршрутизации и адресации Internet. Следовательно, переход к долговременному решению не подвержен влиянию реализации данного плана.
9. Заключение
Мы знаем об усложнении маршрутизации и росте числа выделенных номеров сетей. При наблюдаемой скорости роста можно предположить, что адреса закончатся в течение нескольких лет.
Если протоколы междоменной маршрутизации будут поддерживать передачу данных о маршрутах с соответствующими масками, основные сложности, упомянутые в этом документе, будут устранены.
Одним из важных факторов реализации этого плана является число людей, которые согласятся использовать предложенный план.
Если сервис-провайдеры начнут брать плату за анонсирование маршрутов, это станет хорошим стимулом для совместного использования адресного пространства и связанного с этим числа маршрутов, анонсируемых сервис-провайдерам.
10. Рекомендации
NIC следует начать распределение крупных блоков сетей класса C сервис-провайдерам. Каждый блок должен быть выравнен по битовой границе и иметь достаточно большой размер, чтобы его хватило сервис-провайдеру по крайней мере на два года. Далее NIC следует выделить очень большие блоки для континентальных и национальных операторов, чтобы обеспечить дополнительное агрегирование на уровне основных магистральных сетей. В дополнение к сказанному NIC следует изменить процедуры для домена IN-ADDR.ARPA, чтобы позволить делегирование произвольных частей зоны, выровненных по границе октета.
Сервис провайдеры будут далее распределять блоки адресов класса C (кратные по размеру степеням числа 2) из полученного адресного пространства для своих клиентов.
Всем организациям, включая многодомные, следует получать адреса от своего провайдера (или одного из нескольких провайдеров для многодомных сетей). Эти блоки также следует выравнивать по битовой границе для упрощения агрегирования маршрутов.
Для эффективного использования нового плана распределения адресов и снижения объемов передаваемой маршрутной информации следует организовать соответствующие рабочие группы IETF по созданию обновленных вариантов протоколов междоменной маршрутизации. Реализацию и развертывание этих протоколов следует провести незамедлительно.
11 Литература
[1] Moy, J, “The OSPF Specification Version 2”, RFC 12473, Proteon, Inc., January 1991.
[2] Rekhter, Y., and T. Li, “An Architecture for IP Address Allocation with CIDR”, RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems, September 1993.
12. Вопросы безопасности
Вопросы безопасности не рассматриваются в данном документе.
13. Адреса авторов
Vince Fuller
BARRNet
Pine Hall 115
Stanford, CA, 94305-4122
EMail: vaf@Stanford.EDU
Tony Li
cisco Systems, Inc.
1525 O’Brien Drive
Menlo Park, CA 94025
EMail: tli@cisco.com
Jessica (Jie Yun) Yu
Merit Network, Inc.
1071 Beal Ave.
Ann Arbor, MI 48109
EMail: jyy@merit.edu
Kannan Varadhan
Internet Engineer, OARnet
1224, Kinnear Road,
Columbus, OH 43212
EMail: kannan@oar.net
Перевод на русский язык
Николай Малых
1Classless Inter-Domain Routing
2Блок адресов организации перестает быть доступным через данного провайдера. Прим. перев.
