RFC 1631 | Транслятор сетевых IP-адресов (NAT)

RFC 1631 | Транслятор сетевых IP-адресов (NAT)

Аннотация

Две наиболее неотложные проблемы, с которыми сталкивается IP-Интернет, — это истощение IP-адресов и масштабирование при маршрутизации. Долгосрочные и краткосрочные решения этих проблем находятся в стадии разработки. Краткосрочным решением является CIDR (бесклассовая междоменная маршрутизация). Долгосрочные решения состоят из различных предложений по новым интернет-протоколам с большими адресами.

Скачать оригинальный документ на английском языке RFC 1631 PDF

 

Вполне возможно, что CIDR будет недостаточно для поддержания IP-Интернета до тех пор, пока не появятся долгосрочные решения. В этой записке предлагается другое краткосрочное решение, повторное использование адресов, которое дополняет CIDR или даже делает его ненужным. Решение для повторного использования адресов заключается в размещении сетевых трансляторов адресов (NAT) на границах доменов-заглушек. Каждая коробка NAT имеет таблицу, состоящую из пар локальных IP-адресов и глобально уникальных адресов. IP-адреса внутри домена-заглушки не являются глобально уникальными. Они повторно используются в других доменах, таким образом решая проблему истощения адресов. Глобально уникальные IP-адреса назначаются в соответствии с текущими схемами распределения адресов CIDR. CIDR решает проблему масштабирования. Основным преимуществом NAT является то, что он может быть установлен без изменений на маршрутизаторах или хостах. Эта памятка представляет предварительный дизайн для NAT, и обсуждает его плюсы и минусы.

 

Оглавление

1. Введение
2. Обзор NAT
3. Различные аспекты NAT
3.1 Адресные пространства
3.2 Маршрутизация через NAT
3.3 Манипуляции с заголовками
4. Выводы
5. Ссылки
6. Вопросы безопасности
7. Адреса авторов

 

Статус этой заметки

Эта памятка содержит информацию для интернет-сообщества. В этой заметке не указан интернет-стандарт любого рода. Распространение этой заметки не ограничено.

 

1. Введение

Две наиболее неотложные проблемы, с которыми сталкивается IP-Интернет, — это истощение IP-адресов и масштабирование при маршрутизации. Долгосрочные и краткосрочные решения этих проблем находятся в стадии разработки. Краткосрочным решением является CIDR (бесклассовая междоменная маршрутизация) [2]. Долгосрочные решения состоят из различных предложений по новым интернет-протоколам с большими адресами.

До тех пор, пока долгосрочные решения не будут готовы, простой способ удержать спрос на IP-адреса заключается в повторном использовании адресов. Это решение использует тот факт, что очень маленький процент хостов в домене-заглушке взаимодействует вне домена в любой момент времени. (Домен-заглушка — это домен, такой как корпоративная сеть, который обрабатывает только трафик, исходящий или предназначенный для узлов в домене). Действительно, многие (если не большинство) хостов никогда не общаются вне своего домена-заглушки. Из-за этого только подмножество IP-адресов внутри домена-заглушки необходимо преобразовать в IP-адреса, которые являются глобально уникальными, когда требуется внешняя связь.

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

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

 

2. Обзор NAT

Дизайн, представленный в этой заметке, называется NAT для Network Address Translator. NAT — это функция маршрутизатора, которую можно настроить, как показано на рисунке 1. Только маркер-заглушка требует модификации.

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

Рисунок 1 - Конфигурация NAT
Рисунок 1 — Конфигурация NAT

Например, в примере на рисунке 2 обе заглушки A и B внутренне используют адрес класса A 10.0.0.0. NAT-заглушке A назначается адрес класса C 198.76.29.0, а NAT-заглушке B назначается адрес класса C 198.76.28.0. Адреса класса C глобально уникальны, их не могут использовать другие блоки NAT.

Рисунок 2 - Основные операции NAT
Рисунок 2 — Основные операции NAT

Когда хост-заглушка 10.33.96.5 хочет отправить пакет на хост-заглушку B 10.81.13.22, он использует глобально уникальный адрес 198.76.28.4 в качестве пункта назначения и отправляет пакет своему первичному маршрутизатору. Маршрутизатор-заглушка имеет статический маршрут для сети 198.76.0.0, поэтому пакет перенаправляется на WAN-канал. Тем не менее, NAT преобразует адрес источника 10.33.96.5 заголовка IP с глобально уникальным 198.76.29.7 перед пересылкой пакета. Аналогично, IP-пакеты на обратном пути проходят через аналогичные преобразования адресов.

Обратите внимание, что это не требует никаких изменений для хостов или маршрутизаторов. Например, что касается хоста-заглушки A, 198.76.28.4 — это адрес, используемый хостом в заглушке B. Преобразования адресов полностью прозрачны.

Конечно, это всего лишь простой пример. Есть множество вопросов, которые необходимо изучить. В следующем разделе мы обсудим различные аспекты NAT.

 

3. Различные аспекты NAT

 

3.1 Адресные пространства

Разделение многоразовых и одноразовых адресов

Для правильной работы NAT необходимо разделить пространство IP-адресов на две части — многократно используемые адреса, используемые для создания заглушенных доменов, и глобально уникальные адреса. Мы называем адреса многократного использования локальными адресами, а глобально уникальные адреса — глобальными адресами. Любой данный адрес должен быть локальным или глобальным адресом. Здесь нет перекрытия.

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

Первоначальное присвоение локальных и глобальных адресов

Один адрес класса А должен быть выделен для локальных сетей. (См. RFC 1597 [3].) Этот адрес может затем использоваться для интернет-сетей без подключения к Интернету. Затем NAT предоставляет простой способ изменить экспериментальную сеть на «настоящую» сеть, преобразовав экспериментальные адреса в глобально уникальные интернет-адреса.

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

 

3.2 Маршрутизация через NAT

Маршрутизатор, на котором работает NAT, никогда не должен объявлять локальные сети для магистрали. За пределами заглушки могут быть известны только сети с глобальными адресами. Однако глобальная информация, которую NAT получает от маршрутизатора-заглушки, может быть объявлена ​​в заглушке обычным способом.

Частные сети, охватывающие магистральные сети

Во многих случаях частная сеть (например, корпоративная сеть) будет распределена по разным местоположениям и будет использовать общедоступную магистраль для связи между этими местоположениями. В этом случае нежелательно выполнять преобразование адресов, так как большое количество хостов может захотеть обмениваться данными по магистрали, что требует больших таблиц адресов, и потому что будет больше приложений, которые зависят от настроенных адресов, а не на сервер имен. Мы называем такую ​​частную сеть заглушкой с магистральным разделением.

Заглушки с разделенными магистралями должны вести себя так, как если бы они были разделенными заглушками. То есть маршрутизаторы во всех разделах должны поддерживать маршруты к локальным адресным пространствам всех разделов. Конечно, (публичные) магистрали не поддерживают маршруты к каким-либо локальным адресам. Поэтому пограничные маршрутизаторы должны туннелировать через магистрали, используя инкапсуляцию. Для этого каждое поле NAT будет выделять один глобальный адрес для туннелирования. Когда NAT-блок x в разделе-заглушке X желает доставить пакет в раздел-заглушку Y, он инкапсулирует пакет в заголовок IP с адресом назначения, установленным в глобальный адрес NAT-блока y, который был зарезервирован для инкапсуляции. Когда NAT box y получает пакет с этим адресом назначения, он декапсулирует IP-заголовок и маршрутизирует пакет внутри страны.

 

3.3 Манипуляции с заголовками

Помимо изменения IP-адреса, NAT должен изменить контрольную сумму IP и контрольную сумму TCP. Помните, что контрольная сумма TCP также охватывает псевдо заголовок, который содержит адрес источника и назначения. NAT также должен следить за ICMP и FTP и изменять места, где появляется IP-адрес. Несомненно, есть и другие места, где необходимо внести изменения. Надеемся, что большинство таких приложений будет обнаружено во время экспериментов с NAT.

Изменения контрольной суммы для IP и TCP просты и эффективны. Поскольку оба используют одну сумму дополнения, достаточно рассчитать арифметическую разницу между адресами до и после перевода и добавить ее к контрольной сумме. Единственная сложная часть — определение того, привело ли сложение к оборачиванию (в положительном или отрицательном направлении) контрольной суммы. Если это так, 1 должен быть добавлен или вычтен, чтобы удовлетворить арифметику своего дополнения. Пример кода (в C) для этого выглядит следующим образом:

void checksumadjust(unsigned char *chksum, unsigned char *optr,
int olen, unsigned char *nptr, int nlen)
/* assuming: unsigned char is 8 bits, long is 32 bits.
— chksum points to the chksum in the packet
— optr points to the old data in the packet
— nptr points to the new data in the packet
*/
{
long x, old, new;
x=chksum[0]*256+chksum[1];
x=~x;
while (olen) {
if (olen==1) {
old=optr[0]*256+optr[1];
x-=old & 0xff00;
if (x<=0) { x—; x&=0xffff; }
break;
}
else {
old=optr[0]*256+optr[1]; optr+=2;
x-=old & 0xffff;
if (x<=0) { x—; x&=0xffff; }
olen-=2;
}
}
while (nlen) {
if (nlen==1) {
new=nptr[0]*256+nptr[1];
x+=new & 0xff00;
if (x & 0x10000) { x++; x&=0xffff; }
break;
}
else {
new=nptr[0]*256+nptr[1]; nptr+=2;
x+=new & 0xffff;
if (x & 0x10000) { x++; x&=0xffff; }
nlen-=2;
}
}
x=~x;
chksum[0]=x/256; chksum[1]=x & 0xff;
}

Аргументы команды PORT протокола передачи файлов (FTP) включают IP-адрес (в ASCII!). Если IP-адрес в команде PORT является локальным по отношению к домену-заглушке, то NAT должен заменить его. Поскольку адрес закодирован в ASCII, это может привести к изменению размера пакета (например, 10.18.177.42 — 12 символов ASCII, а 193.45.228.137 — 14 символов ASCII). Если новый размер такой же, как и предыдущий, корректировать нужно только контрольную сумму TCP (снова). Если новый размер меньше, чем предыдущий, ноли ASCII могут быть вставлены, но это не гарантируется. Если новый размер больше предыдущего, порядковые номера TCP также должны быть изменены.

Специальная таблица используется для исправления последовательности TCP и подтверждения номеров с портом источника FTP или портом назначения FTP. Записи таблицы должны иметь источник, пункт назначения, порт источника, порт назначения, начальный порядковый номер, дельта для порядковых номеров и временную метку. Новые записи создаются только тогда, когда видны команды FTP PORT. Начальные порядковые номера используются для определения, является ли порядковый номер пакета до или после последней команды FTP PORT (дельта может быть увеличена для каждой команды FTP PORT). Порядковые номера увеличиваются, а подтверждающие номера уменьшаются. Если бит FIN установлен в одном из пакетов, соответствующая запись может быть удалена вскоре после этого (1 минута должна быть безопасной). Записи, которые не были использованы, например, для 24 часа должны быть безопасны для удаления тоже.

Корректировка порядкового номера должна быть тщательно закодирована, чтобы не повредить производительности для TCP в целом. Конечно, если сеанс FTP зашифрован, команда PORT не будет выполнена.

Если сообщение ICMP передается через NAT, может потребоваться две модификации адреса и три модификации контрольной суммы. Это связано с тем, что большинство сообщений ICMP содержат часть исходного IP-пакета в теле. Поэтому для того, чтобы NAT был полностью прозрачен для хоста, IP-адрес IP-заголовка, встроенного в часть данных пакета ICMP, должен быть изменен, поле контрольной суммы того же IP-заголовка должно быть соответственно изменено, а контрольная сумма заголовка ICMP необходимо изменить, чтобы отразить изменения в заголовке IP и контрольной сумме в теле ICMP. Кроме того, обычный IP-заголовок также должен быть изменен, как уже описано.

Не совсем понятно, действительно ли нужно изменять информацию заголовка IP в части тела ICMP. Это зависит от того, действительно ли какой-либо хост-код просматривает эту информацию заголовка IP. Действительно, может быть полезно предоставить точный заголовок, видимый маршрутизатором или хостом, который выдал сообщение ICMP, чтобы помочь в отладке. В любом случае, для сообщений Echo и Timestamp не требуется никаких модификаций, и NAT никогда не должен обрабатывать сообщение Redirect. Сообщения SNMP могут быть изменены, но это даже более сомнительно, чем для сообщений ICMP, что это будет необходимо.

Приложения с IP-адресом Контент

Любое приложение, которое несет (и использует) IP-адрес внутри приложения, не будет работать через NAT, если NAT не знает о таких случаях и не выполняет соответствующую трансляцию. NAT не может или даже не желает знать обо всех таких приложениях. И, если используется шифрование, то NAT не сможет выполнить перевод.

Для таких систем может быть возможно избежать использования NAT, если узлам, на которых они работают, назначены глобальные адреса. Может ли это работать, зависит от возможностей алгоритма внутридоменной маршрутизации и внутренней топологии. Это связано с тем, что глобальный адрес должен объявляться в алгоритме внутридоменной маршрутизации. При использовании алгоритма маршрутизации с низкими характеристиками, такого как RIP, хосту может потребоваться собственное адресное пространство класса C, которое должно объявляться не только внутренне, но и внешне (что наносит ущерб глобальному масштабированию). С помощью высокопроизводительного алгоритма маршрутизации, такого как OSPF, адрес хоста может передаваться индивидуально и может быть получен из таблицы NAT.

Вопросы конфиденциальности, безопасности и отладки

К сожалению, NAT уменьшает количество вариантов обеспечения безопасности. При использовании NAT все, что содержит IP-адрес или информацию, полученную из IP-адреса (например, контрольную сумму заголовка TCP), не может быть зашифровано. Хотя большинство шифрований на уровне приложений должно быть в порядке, это предотвращает шифрование заголовка TCP.

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

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

 

4. Выводы

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

Отрицательные характеристики:

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

2. Это увеличивает вероятность неправильной адресации.

3. Это ломает определенные приложения (или, по крайней мере, делает их более сложными для запуска).

4. Скрывает личность хозяев. Хотя это имеет преимущество конфиденциальности, это, как правило, отрицательный эффект.

5. Проблемы с SNMP, DNS, … вы называете это.

Текущие реализации

Пол и Тони внедрили экспериментальный прототип NAT в общедоступном программном обеспечении TCP / IP KA9Q [1]. Эта реализация манипулирует адресами и контрольными суммами IP.

Кьельд реализовал NAT в IP-роутере Cray Communications. Реализация была протестирована с Telnet и FTP. Эта реализация манипулирует адресами, контрольными суммами IP, номерами последовательностей / подтверждений TCP и командами FTP PORT.

Прототипы продемонстрировали, что IP-адреса могут быть прозрачно переведены на хосты в пределах ограничений, описанных в этом документе.

 

5. Ссылки

[1] Karn, P., «KA9Q», anonymous FTP from ucsd.edu (hamradio/packet/ka9q/docs).

[2] Fuller, V., Li, T., and J. Yu, «Classless Inter-Domain Routing (CIDR) an Address Assignment and Aggregation Strategy», RFC 1519, BARRNet, cisco, Merit, OARnet, September 1993.

[3] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot, «Address Allocation for Private Internets», RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.

 

6. Вопросы безопасности

Вопросы безопасности не обсуждаются в этой записке.

 

7. Адреса авторов

Kjeld Borch Egevang
Cray Communications
Smedeholm 12-14
DK-2730 Herlev
Denmark
Phone: +45 44 53 01 00
EMail: kbe@craycom.dk

Paul Francis
NTT Software Lab
3-9-11 Midori-cho Musashino-shi
Tokyo 180 Japan
Phone: +81-422-59-3843
Fax +81-422-59-3765
EMail: francis@cactus.ntt.jp

Благодарности

Эта заметка основана на статье Пола Фрэнсиса (ранее Цучия) и Тони Энг, опубликованной в журнале Computer Communication Review, январь 1993 года. У Пола была концепция повторного использования адреса от Ван Якобсона.

Кьельд Борх Эгеванг отредактировал документ, подготовив эту заметку, и ввел настройку порядковых номеров для FTP. Спасибо Джейкобу Майклу Кристенсену за его комментарии к идее и тексту (мы долго думали, что мы единственные, у кого была идея).