1 .

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

3 .
   Другой проблемой, которая может возникнуть при использовании частных адресов, является необходимость смены адресов при объединении двух или более сетей, если они использовали частные адреса из перекрывающихся блоков. Если вернуться к списку компаний, для которых рекомендовалось использовать частные адреса (параграф 2), можно заметить, что такие компании (сети) достаточно часто объединяются. Если в каждой из объединяемых сетей использовались частные адреса, в объединенной сети требование уникальности адресов каждого хоста может нарушаться. В результате возникает необходимость смены адресов для всех или части хостов.
   Расходы на замену адресов могут быть снижены за счет использования средств автоматического распределения адресов (например, протокола DHCP). При выборе зоны использования частных адресов мы рекомендуем для таких зон сразу применять системы автоматического распределения адресов 4 . Вопросами замены адресов (процедура, рекомендации) занимается специальная рабочая группа IETF (PIER Working Group).

5 . Для того, чтобы избежать остановки сети при таких изменениях, целесообразно группировать хосты в подсети с учетом перспектив дальнейшего использования этих хостов.
   Если подходящая схема организации подсетей может быть разработана и будет поддерживаться используемым в сети оборудованием, разумно воспользоваться для частной сети 24-битовым блоком адресов (сеть класса А) — это позволит создать достаточно большую сеть. Если разделение на подсети нереально, можно воспользоваться 16-битовым (сеть класса С) или 20-битовым (сеть класса В) блоком частных адресов.
   Может показаться заманчивой перспектива использования частных и публичных адресов в одной физической сети. Хотя такое решение допустимо, оно содержит подводные камни, связанные с существованием нескольких подсетей IP в одной сети канального уровня. Рекомендуем с осторожностью использовать такой подход 6 .
   Настоятельно рекомендуется для маршрутизаторов, соединяющих предприятие с внешними сетями, использовать соответствующие фильтры для пакетов и маршрутов, предотвращающие передачу пакетов с частными адресами и информации о внутренних маршрутах во внешние по отношению к предприятию сети. Такие фильтры нужно устанавливать на маршрутизаторах по обе стороны канала между сетями. На входе в сеть предприятия должна также отфильтровываться вся входящая маршрутная информация для того, чтобы предотвратить ненужные проблемы с маршрутизацией во внутренней сети.
   Две частных сети могут обмениваться информацией через публичную сеть, если использование частных адресов в обеих сетях согласовано. Для решения таких задач на границах частных сетей следует использовать инкапсуляцию. Если несколько организаций, использующих частные адреса из указанных в данном документе блоков, захотят впоследствии связать свои сети по протоколу IP, существует риск нарушения требования уникальности адреса для каждого хоста в масштабе объединенной сети. Для снижения такого риска рекомендуется выбирать для использования группу адресов из допустимого блока случайным образом.
   Если предприятие использует частные адреса или комбинацию частных и публичных адресов, клиенты DNS за пределами предприятия не должны видеть адресов из частного блока, поскольку такие адреса будут вводить в заблуждение другие системы. Одним из способов решения этой проблемы является использование уполномоченных серверов (authority server) для каждой зоны DNS, содержащей частные и публичные адреса. Один сервер будет доступен из публичной сети и должен содержать только те адреса частной сети, которые доступны извне (публичные адреса). Другой сервер будет доступен только из частной сети и должен содержать полный набор данных, включая частные адреса и публичные адреса, доступные из частной сети. Для того, чтобы обеспечить согласованность работы серверов, они должны использовать общий набор данных, но доступная из публичной сети информация должна соответствующим образом фильтроваться. Реализация такого решения влечет за собой некоторое усложнение сервера имен.

yakov@cisco.com
 
   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: 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.
   201 IN . Shoreline Blvd.
   Mountain View , CA 94043-1389
   Phone:+1415 960 1980
   Fax: +1415 9619584
   EMail: lear@sgi.com
   Перевод на русский язык
   Николай Малых nmalvkh@bilim.com
 
   1 Доступной пользователям из внешних по отношению к предприятию сетей. Прим. перев.
   2 Для обозначения таких шлюзов часто используется термин прокси — proxy. Прим. перев.
   3 Такая проблема зачастую возникает при смене провайдера Internet. Прим. перев.
   4 В этом случае для смены адресов не потребуется заново настраивать каждый хост — достаточно будет лишь заменить блок распределяемых адресов на сервере DHCP. Прим. перев.
   5 В таких случаях может также возникать необходимость в изменении сетевых соединений на физическом уровне.
   6 Современные средства поддержки VLAN позволяют достаточно легко решить эту проблему. Прим. перев.