RFC 1918. Распределение адресов в частных ИП-сетях   ::   Ietf

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

Если предприятие использует частные адреса или комбинацию частных и публичных адресов, клиенты 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 Доступной пользователям из внешних по отношению к предприятию сетей. Прим. перев.

2 Для обозначения таких шлюзов часто используется термин прокси — proxy. Прим. перев.

3 Такая проблема зачастую возникает при смене провайдера Internet. Прим. перев.

4 В этом случае для смены адресов не потребуется заново настраивать каждый хост — достаточно будет лишь заменить блок распределяемых адресов на сервере DHCP. Прим. перев.

5 В таких случаях может также возникать необходимость в изменении сетевых соединений на физическом уровне.

6 Современные средства поддержки VLAN позволяют достаточно легко решить эту проблему. Прим. перев.