RFC: 1918
Оригинал: Address Allocation for Private Internets
Предыдущие версии: RFC 1597, RFC 1627
Категория: Лучший современный опыт
Дата публикации:
Авторы: , , , ,
Перевод: Николай Малых

RFC 1918, Страница 4 из 5

5. Практические рекомендации

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

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

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

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

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

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

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

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

2007 - 2017 © Русские переводы RFC, IETF, ISOC.