RFC: 2993
Оригинал: Architectural Implications of NAT
Категория: Информационный
Дата публикации:
Автор:
Перевод: Мельников Дмитрий Анатольевич

Оглавление

1. Введение

Опубликованный в мае 1994 года стандарт RFC-1631, разработанный Kjeld Borch Egevang и Paul Francis, ввел понятие транслятора сетевых адресов, который используется как средство преодоления проблемы уменьшение числа свободных IPv4-адресов. Но авторы этого стандарта не заботились о сущности этого способа. В своей публикации они указали несколько мест, когда потребуется экспериментальный анализ их способа и в дальнейшем необходимо проверить те прикладные службы, которые будут функционировать корректно после обработки заголовков сообщений NAT-модулями.

Теперь, по прошествии нескольких лет, применение NAT-модулей стало повсеместным в Internet. Более того, сейчас проводится работа по адаптации NAT-модулей к IPv6-адресации. Однако, в Internet-сообществе существуют две группы пользователей: стронники и противники применения NAT-модулей. Вот их аргументация:

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

  • Противники смотрят на NAT-модули как на «вредную» технологию. Они ститают, что это «сорняк», который способен «задушить» дальнейшее прогрессивное развитие Internet. Даже понимая, что существует ярко выраженная нехватка IP-адресов, противники применения NAT-модулей рассматривают их как функционально не адекватный способ улучшения работы Internet-сетей, причем граничащий с обманом, который вводит в заблуждение пользователей по поводу упрощения доступа в Internet.

Истина лежит где-то между этими двумя крайне противоположными точками зрения.

В любом случае, очевидно, что NAT-метод нарушает принцип прозрачности сквозного (межтерминального) соединения при доставке IP-пакетов, основываясь на адресной информации в IP-заголовке, и при функционировании протоколов, которые транспортируют адресную информацию в других частях сообщений, отличных от IP-заголовка. Используя специализированные прикладные программные интерфейсы/шлюзы (Application Level Gateway — ALG), сетевые терминалы могут нормально взаимодействовать между собой, невзирая на имеющиеся функциональные проблемы NAT-модулей. Эти функциональные проблемы варьируются в зависимости от ряда факторов, среди которых сетевая топология, топология прикладной службы и использование специфических прикладных служб. С одной стороны, эти проблемы могут быть сравнительно легко преодолимы, когда речь идет о простейшей ситуации, например, когда трафик между двумя оконечными пользователями проходит через сеть, которая не имеет параллельных NAT-модулей. Но, с другой стороны, ситуация может резко усложниться, когда имеет место большое число, порой не нужных, параллельных NAT-модулей, или когда имеют место распределенные и многоузловые прикладные службы, функционирование которых напоминает распределение многостраничного документа. Сложность синхронизации и координации процедур обновления данных, что вызвано необходимостью обеспечения корректного «прохождения трафика» через NAT-модули, растет в геометрической прогрессии с ростом числа терминалов. В больших сетях, это может потребовать от конкретного прикладного процесса или службы обеспечения одновременного обновления данных во всех терминалах.

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