4. Преимущества и недостатки при использовании частных адресов
Очевидным преимуществом использования частных адресов является экономия адресного пространства Internet за счет использования частных адресов во множестве сетей, не связанных напрямую с Internet.
Предприятия также имеют преимущества в результате использования частных адресов. Блоки частных адресов достаточно велики и обеспечивают гибкость и свободу при распределении адресов для хостов частной сети. Это позволяет обойтись без смены адресов при внесении в сеть изменений или ее расширении.
По разным причинам в сети Internet уже возникали ситуации, когда предприятия, не подключенные к Internet, использовали для своих хостов IP-адреса из публичных блоков без согласования с IANA. В некоторых случаях эти адреса уже были выделены другим предприятиям. Если сеть с такими адресами потом будет подключаться к Internet, могут возникнуть серьезные проблемы, поскольку маршрутизация IP не может быть корректной при наличии в сети хостов с совпадающими адресами. Хотя провайдеры Internet должны предотвращать подобные ситуации путем использования маршрутных фильтров, на практике такая фильтрация осуществляется не всегда. Использование частных адресов в корпоративных сетях позволяет избежать проблем с маршрутизацией при подключении частной сети к Internet Основным неудобством при использовании частных адресов является возможность возникновения существенных проблем при подключении корпоративной сети к Internet.
Если в сети используются частные адреса, то при ее подключении к Internet потребуется смена адресов IP для каждого хоста, которому предоставляется прямой доступ в Internet Обычно расходы на такую замену адресов пропорциональны числу хостов, которые переносятся из частной сети в публичную. Однако, как было отмечено выше, смена адресов может потребоваться и при использовании в частной сети уникальных адресов 3 .
Другой проблемой, которая может возникнуть при использовании частных адресов, является необходимость смены адресов при объединении двух или более сетей, если они использовали частные адреса из перекрывающихся блоков. Если вернуться к списку компаний, для которых рекомендовалось использовать частные адреса (параграф 2), можно заметить, что такие компании (сети) достаточно часто объединяются. Если в каждой из объединяемых сетей использовались частные адреса, в объединенной сети требование уникальности адресов каждого хоста может нарушаться. В результате возникает необходимость смены адресов для всех или части хостов.
Расходы на замену адресов могут быть снижены за счет использования средств автоматического распределения адресов (например, протокола DHCP). При выборе зоны использования частных адресов мы рекомендуем для таких зон сразу применять системы автоматического распределения адресов 4 . Вопросами замены адресов (процедура, рекомендации) занимается специальная рабочая группа IETF (PIER Working Group).
5. Практические рекомендации
Одним из возможных вариантов является разработка на начальном этапе плана распределения адресов для внутренней части сети, не связанной напрямую с другими сетями. После этого определяются публичные подсети и для них выделяются соответствующие блоки адресов.
Такой подход не порождает фиксированной навсегда схемы. Если статус одного или нескольких хостов впоследствии изменяется (от частного к публичному или наоборот), потребуется сменить адреса только для таких хостов 5 . Для того, чтобы избежать остановки сети при таких изменениях, целесообразно группировать хосты в подсети с учетом перспектив дальнейшего использования этих хостов.
Если подходящая схема организации подсетей может быть разработана и будет поддерживаться используемым в сети оборудованием, разумно воспользоваться для частной сети 24-битовым блоком адресов (сеть класса А) — это позволит создать достаточно большую сеть. Если разделение на подсети нереально, можно воспользоваться 16-битовым (сеть класса С) или 20-битовым (сеть класса В) блоком частных адресов.
Может показаться заманчивой перспектива использования частных и публичных адресов в одной физической сети. Хотя такое решение допустимо, оно содержит подводные камни, связанные с существованием нескольких подсетей IP в одной сети канального уровня. Рекомендуем с осторожностью использовать такой подход 6 .
Настоятельно рекомендуется для маршрутизаторов, соединяющих предприятие с внешними сетями, использовать соответствующие фильтры для пакетов и маршрутов, предотвращающие передачу пакетов с частными адресами и информации о внутренних маршрутах во внешние по отношению к предприятию сети. Такие фильтры нужно устанавливать на маршрутизаторах по обе стороны канала между сетями. На входе в сеть предприятия должна также отфильтровываться вся входящая маршрутная информация для того, чтобы предотвратить ненужные проблемы с маршрутизацией во внутренней сети.
Две частных сети могут обмениваться информацией через публичную сеть, если использование частных адресов в обеих сетях согласовано. Для решения таких задач на границах частных сетей следует использовать инкапсуляцию. Если несколько организаций, использующих частные адреса из указанных в данном документе блоков, захотят впоследствии связать свои сети по протоколу IP, существует риск нарушения требования уникальности адреса для каждого хоста в масштабе объединенной сети. Для снижения такого риска рекомендуется выбирать для использования группу адресов из допустимого блока случайным образом.
Если предприятие использует частные адреса или комбинацию частных и публичных адресов, клиенты DNS за пределами предприятия не должны видеть адресов из частного блока, поскольку такие адреса будут вводить в заблуждение другие системы. Одним из способов решения этой проблемы является использование уполномоченных серверов (authority server) для каждой зоны DNS, содержащей частные и публичные адреса. Один сервер будет доступен из публичной сети и должен содержать только те адреса частной сети, которые доступны извне (публичные адреса). Другой сервер будет доступен только из частной сети и должен содержать полный набор данных, включая частные адреса и публичные адреса, доступные из частной сети. Для того, чтобы обеспечить согласованность работы серверов, они должны использовать общий набор данных, но доступная из публичной сети информация должна соответствующим образом фильтроваться. Реализация такого решения влечет за собой некоторое усложнение сервера имен.
6. Вопросы безопасности
В данной работе вопросы безопасности не рассматриваются.
7. Заключение
При использовании описанной в документе схемы даже крупным предприятиям требуются сравнительно небольшие блоки публичных адресов IP. В результате существенно снижается острота проблемы нехватки адресов в Internet и обеспечивается более эффективное использование уникальных в масштабах Сети адресов IP. Предприятие получает возможность гибкого распределения адресов из любого частного блока. Однако использование частных адресов в сети предприятия может потребовать замены адресов для части хостов при подключении корпоративной сети к Internet или другим IP-сетям.
8. Благодарности
Авторы вьфажают свою признательность Tony Bates (MCI), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (Bay Networks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (Cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (Bay Networks), 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., T. Li, «An Architecture for IP Address Allocation with CIDR», RFC 1518, September 1993.
RFC1519 — Fuller, V., Li, Т., Yu, J., 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: [email protected]
Robert G Moskowitz
Chrysler Corporation
CEVIS: 424-73-00
25999 Lawrence Ave
Center Line , MI 48015
Phone:+1810 758 8212
Fax:+1810 758 8173
EMail: [email protected]
Daniel Karrenberg
RIPE Network Coordination Centre
Kruislaan 409
1098 SJ Amsterdam , the Netherlands
Phone:+31 20 592 5065
Fax:+31 20 592 5090
EMail: [email protected]
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: [email protected]
Eliot Lear
Mail Stop 15-730
Silicon Graphics, Inc.
201 IN . Shoreline Blvd.
Mountain View , CA 94043-1389
Phone:+1415 960 1980
Fax: +1415 9619584
EMail: [email protected]
Перевод на русский язык
Николай Малых [email protected]
1 Доступной пользователям из внешних по отношению к предприятию сетей. Прим. перев.
