⌕ Поиск по атласу

Полный русский перевод · RFC1918

RFC1918 · Выделение адресов для частных интернет-сетей

Address Allocation for Private Internets

Карточка документа · Архив принятого перевода · Официальный источник

Содержание

О документе


Рабочая группа по сетям                                      Y. Rekhter
Запрос комментариев: 1918                              Cisco Systems
Устаревает: 1627, 1597                                  B. Moskowitz
BCP: 5                                               Chrysler Corp.
Категория: Лучшая современная практика                 D. Karrenberg
                                                             RIPE NCC
                                                       G. J. de Groot
                                                             RIPE NCC
                                                              E. Lear
                                               Silicon Graphics, Inc.
                                                        Февраль 1996

                Распределение адресов для частных интернетов

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

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

1. Введение

Для целей настоящего документа предприятием является субъект,
   автономно эксплуатирующий сеть с использованием TCP/IP и, в
   частности, определяющий план адресации и назначения адресов внутри
   этой сети.

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

2. Мотивация

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

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

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

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

   Обычно всем хостам, использующим TCP/IP, назначались глобально
   уникальные адреса. Чтобы продлить срок использования адресного
   пространства IPv4, реестры адресов требуют больше обоснований, чем
   когда-либо прежде, что затрудняет для организаций получение
   дополнительного адресного пространства [RFC1466].

   Хосты внутри предприятий, использующих IP, можно разделить на три
   категории:

      Категория 1: хосты, которым не требуется доступ к хостам в
                   других предприятиях или в Интернете в целом; хосты
                   этой категории могут использовать IP-адреса,
                   однозначные внутри предприятия, но неоднозначные
                   между предприятиями.

      Категория 2: хосты, которым необходим доступ к ограниченному
                   набору внешних служб (например, E-mail, FTP,
                   netnews, удалённый вход), который может
                   обслуживаться посредническими шлюзами (например,
                   шлюзами прикладного уровня). Для многих хостов этой
                   категории неограниченный внешний доступ
                   (обеспечиваемый IP-связностью) может быть не нужен
                   и даже нежелателен по причинам приватности/
                   безопасности. Как и хосты первой категории, такие
                   хосты могут использовать IP-адреса, однозначные
                   внутри предприятия, но неоднозначные между
                   предприятиями.

      Категория 3: хосты, которым необходим доступ сетевого уровня за
                   пределами предприятия (обеспечиваемый IP-
                   связностью); хостам последней категории требуются
                   IP-адреса, глобально однозначные.

   Хосты первой и второй категорий далее будут называться «частными».
   Хосты третьей категории далее будут называться «общедоступными».

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

   Несколько примеров, в которых внешняя связность может не требоваться:

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

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

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

         - Интерфейсам маршрутизаторов во внутренней сети обычно не
           требуется быть непосредственно доступными извне предприятия.

3. Частное адресное пространство

Internet Assigned Numbers Authority (IANA) зарезервировал следующие
   три блока адресного пространства IP для частных интернетов:

     10.0.0.0        -   10.255.255.255  (префикс 10/8)
     172.16.0.0      -   172.31.255.255  (префикс 172.16/12)
     192.168.0.0     -   192.168.255.255 (префикс 192.168/16)

   Первый блок далее будет называться «24-битным блоком», второй —
   «20-битным блоком», а третий — «16-битным блоком». Обратите внимание,
   что в обозначениях, предшествовавших CIDR, первый блок представляет
   собой всего лишь один номер сети класса A, второй блок — набор из 16
   смежных номеров сетей класса B, а третий блок — набор из 256 смежных
   номеров сетей класса C.

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

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

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

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

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

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

   Косвенные ссылки на такие адреса следует ограничивать пределами
   предприятия. Яркими примерами таких ссылок являются DNS Resource
   Records и иная информация, ссылающаяся на внутренние частные адреса.
   В частности, поставщикам интернет-услуг следует принимать меры для
   предотвращения такой утечки.

4. Преимущества и недостатки использования частного адресного пространства

Очевидное преимущество использования частного адресного пространства
   для Интернета в целом состоит в сохранении глобально уникального
   адресного пространства за счёт отказа от его использования там, где
   глобальная уникальность не требуется.

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

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

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


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

   Стоимость перенумерации вполне может быть снижена благодаря разработке и внедрению средств, упрощающих перенумерацию (например, Dynamic Host Configuration Protocol (DHCP)). При принятии решения об использовании частных адресов мы рекомендуем запросить у поставщиков компьютеров и программного обеспечения сведения о доступности таких средств. Отдельная работа IETF (рабочая группа PIER) направлена на полное документирование требований и процедур перенумерации.

5. Эксплуатационные соображения

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

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

   Если можно разработать подходящую схему разбиения на подсети и она поддерживается соответствующим оборудованием, целесообразно использовать 24-битный блок (сеть класса A) частного адресного пространства и составить план адресации с хорошей возможностью роста. Если разбиение на подсети представляет проблему, можно использовать 16-битный блок (сети класса C) или 20-битный блок (сети класса B) частного адресного пространства.

   Может возникнуть соблазн использовать как публичные, так и частные адреса в одной физической среде. Хотя это возможно, такой проект имеет подводные камни (следует отметить, что они не связаны с использованием частных адресов, а обусловлены наличием нескольких IP-подсетей в общей канальной подсети Data Link). Мы советуем проявлять осторожность в этой области.

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

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

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

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

   содержит только отфильтрованную версию. С предоставлением таких возможностей связана определённая дополнительная сложность.

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

В этой записке вопросы безопасности не рассматриваются.

7. Заключение

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

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

Мы хотели бы поблагодарить Tony Bates (MCI), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN) и Paul Vixie (Internet Software Consortium) за их рецензию и конструктивные замечания.

9. Ссылки

[RFC1466] Gerich, E., "Guidelines for Management of IP Address
       Space", RFC 1466, Merit Network, Inc., May 1993.

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

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

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

Yakov Rekhter
   Cisco systems
   170 West Tasman Drive
   San Jose, CA, USA
   Phone: +1 914 528 0090
   Fax: +1 408 526-4952
   EMail: yakov@cisco.com

   Robert G Moskowitz
   Chrysler Corporation
   CIMS: 424-73-00
   25999 Lawrence Ave
   Center Line, MI 48015
   Phone: +1 810 758 8212
   Fax: +1 810 758 8173
   EMail: rgm3@is.chrysler.com

   Daniel Karrenberg
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: Daniel.Karrenberg@ripe.net

   Geert Jan de Groot
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: GeertJan.deGroot@ripe.net

   Eliot Lear
   Mail Stop 15-730
   Silicon Graphics, Inc.
   2011 N. Shoreline Blvd.
   Mountain View, CA 94043-1389
   Phone: +1 415 960 1980
   Fax:   +1 415 961 9584
   EMail: lear@sgi.com