Институт Системного Программирования РАН

Использование контекстного метода трансляции адресной информации для обеспечения совместимости протоколов IPv4 и IPv6

В.З.Шнитман, Д.С.Мишин, Д.В.Москалев, Г.В.Ключников


Последняя модификация: 17/01/2002

Аннотация

Переход с протокола IPv4 на протокол IPv6 связан с решением целого ряда проблем. Одной из основных проблем неизбежного переходного периода является проблема обеспечения совместной работы сетей, построенных на базе этих протоколов. Рабочей группой ngtrans IETF (Internet Engineering Task Force) предложено несколько механизмов, которые в совокупности могут обеспечить плавный и безболезненный переход с IPv4 на IPv6. В данной статье рассмотрена реализация одного из таких механизмов - механизма контекстной трансляции, получившего название "трансляция сетевых адресов и протоколов" - (NAT-PT - Network Address Translation and Protocol Translation). Данная работа выполнена по гранту РФФИ 01-07-90393.


Содержание

Введение
Контекстный межпротокольный транслятор
Разновидности NAT-PT
    Работа основного NAT-PT
    Работа двунаправленного NAT-PT
Трансляция протоколов
Коррекция контрольной суммы TCP/UDP/ICMP
Ограничения NAT-PT
Область применения
Реализация
Литература


Введение

IPv6 представляет собой новую версию IP-протокола, разработанную с целью модернизации протокола IPv4, который был разработан в конце 70-х годов. IPv6 по сравнению с IPv4 имеет ряд преимуществ, которые будут способствовать будущему росту Internet и упростят конфигурирование и администрирование IP сетей. IPv6 имеет большее адресное пространство, чем IPv4, модель адресации, которая способствует агрегированию маршрутов и предлагает мощный механизм автоконфигурирования. Со временем ожидается, что рост Internet и потребность в решении plug-and-play приведут к широкой адаптации протокола IPv6.

При переводе Internet на протокол нового поколения IPv6 возникает целый ряд проблем, связанных, как с обеспечением взаимодействия между двумя или большим числом островков IPv6, изолированных в мире IPv4, так и с установлением связи (или некоторого вида связи) между существующим IPv4 миром и нарождающимся миром IPv6. Как правило, решения первого круга проблем основываются на реализации маршрутизаторов с двойным стеком и организации IPv4 туннелей для передачи IPv6 трафика. Для решения второго круга проблем также был предложен ряд механизмов, в основе которых лежат технологии двойного стека, бесконтекстной и контекстной трансляции протоколов, а также организации IPv6 туннелей для передачи IPv4 трафика.

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

Механизм бесконтекстного IP/ICMP транслятора (SIIT) [.] предполагает установку на границе IPv6 сети специального агента, осуществляющего трансляцию протоколов. При этом IPv6 хостам присваиваются специальные, так называемые IPv4-транслированные, адреса. Приходящие извне IPv4 пакеты перенаправляются этому агенту, проходя который, они подвергаются преобразованию к формату протокола IPv6 и пересылаются далее к своим получателям. Ответные пакеты, идущие от IPv6 хостов к IPv4 хостам (это индицируется специальным типом IPv6 адреса назначения), так же должны пройти через IP/ICMP транслятор, но необязательно через тот же самый, так как сам транслятор является бесконтекстным. Пройдя транслятор, IPv6 пакеты становятся IPv4 пакетами и доставляются по назначению. Удобством этой схемы является ее прозрачность для взаимодействующих хостов и полная бесконтекстность, что существенно облегчает ее реализацию и использование. К сожалению, предложение по реализации SIIT [ ] предполагает, что узлам V6 для организации связи с узлами V4 присваивается V4-адрес (точнее IPv4-транслированный адрес), но не описывает механизм присваивания этих адресов.

Механизм контекстной IP/ICMP трансляции (NAT-PT) является логическим продолжением предыдущего. Для динамического присваивания адресов V6 узлам NAT-PT использует пул V4-адресов, когда через границы V4-V6 инициируются сеансы связи. Предполагается, что V4-адреса являются глобально уникальными. NAT-PT для обеспечения прозрачной маршрутизации дейтаграмм, пересекающих области различной адресации, связывает адреса в сети V6 с адресами в сети V4 и, наоборот. Этот механизм не требует проведения каких-либо изменений в оконечных узлах, и маршрутизация IP-пакетов для оконечных узлов оказывается совершенно прозрачной. Однако он требует, чтобы NAT-PT отслеживал сеансы связи, которые он поддерживает, и предполагает, что входящие и исходящие дейтаграммы, относящиеся к некоторому сеансу, проходят через один и тот же маршрутизатор с установленным NAT-PT. Объединение механизма протокольной трансляций SIIT с возможностями динамической трансляции адресов NAT и соответствующими шлюзами прикладного уровня (ALG), предоставляет собой полное решение, которое позволит огромному числу широко используемых приложений взаимодействовать между узлами, работающими только на протоколе IPv6, и узлами, работающими только на протоколе IPv4, не требуя внесения никаких изменений в эти приложения. Основное предположение для применения NAT-PT заключается в том, чтобы он использовался, только если не возможны никакие иные средства взаимодействия между узлами - собственно IPv6 или IPv6 через туннели IPv4. Другими словами, цель данного механизма заключается в том, чтобы использовать трансляцию только между узлами, работающими только на протоколе IPv6, и узлами, работающими только на протоколе IPv4, в то время как трансляцию между узлами, работающими только на протоколе IPv6, и IPv4-частью узлов с двойным стеком, необходимо реализовать с помощью других альтернативных механизмов.

Ниже этот механизм рассматривается более подробно.


Контекстный межпротокольный IP/ICMP транслятор

Термин "трансляция сетевых адресов" (NAT - Network Address Translation) означает метод, с помощью которого осуществляется отображение IP-адресов одной области адресов на другую с целью обеспечения для хостов прозрачной маршрутизации пакетов между этими адресными областями. Обычно устройства NAT используются для подсоединения изолированной области адресов с частными незарегистрированными адресами к внешней области, в которой используются глобально уникальные зарегистрированные адреса. Работа и разновидности устройств, осуществляющих трансляцию сетевых адресов для IPv4 сетей, определены в RFC 2663 [ ]. Но для обеспечения совместимости между IPv4 и IPv6 сетями потребовалась разработка специального механизма контекстной трансляции, получившего название "трансляция сетевых адресов и протоколов" - (NAT-PT - Network Address Translation and Protocol Translation). Подробно работа и разновидности устройств NAT-PT определены в RFC 2766 [ ]. Данный механизм обеспечивает прозрачную маршрутизацию пакетов оконечных узлов, находящихся в области IPv6, для связи с оконечными узлами, находящимися в области IPv4, и наоборот. С этой целью в NAT-PT, как можно видеть из его названия, объединяются два метода - собственно механизм трансляции сетевых адресов (RFC 2663) и механизм трансляции протоколов V6/V4, который описан в RFC 2765 [ ]. Эта схема не требует наличия двухстековых реализаций или специальных методов маршрутизации.


Разновидности NAT-PT

В RFC 2766 [ ] на данный механизм трансляции определены следующие варианты его реализации: Традиционный NAT-PT (Traditional NAT-PT) - этот механизм позволяет хостам, находящимся в сети V6, обращаться к хостам, находящимся в сети V4. В традиционном NAT-PT сеансы связи являются однонаправленными, исходящими из сети V6. Он отличается от двунаправленного NAT-PT, который позволяет инициировать сеансы связи в обоих направлениях, исходящем и входящем. Также, как и в традиционном V4 NAT, имеются две разновидности традиционного NAT-PT, а именно: основной NAT-PT (Basic NAT-PT) и NAPT-PT (Network Address Port Translation and Protocol Translation).

В основном NAT-PT резервируется некоторый блок адресов V4, которые используются для трансляции адресов V6-хостов при порождении последними сеансов связи с V4-хостами, находящимися во внешнем домене. Для пакетов, исходящих из домена V6, транслируются IP-адрес источника и связанные с ним поля, например, контрольные суммы заголовков IP, TCP, UDP и ICMP. Для входящих пакетов транслируются IP-адрес места назначения и перечисленные выше контрольные суммы.

Механизм NAPT-PT распространяет идею трансляции на один шаг дальше и осуществляет дополнительно трансляцию транспортных идентификаторов (например, номеров портов TCP и UDP, или идентификаторов запросов ICMP). Этот механизм позволяет мультиплексировать транспортные идентификаторы некоторого числа V6-хостов в транспортные идентификаторы единственного присвоенного V4-адреса. Таким образом, NAPT-PT позволяет множеству V6-хостов разделять один V4-адрес. Заметим, что механизм NAPT-PT может быть объединен с основным NAT-PT так, что одновременно с трансляцией портов будет использоваться пул внешних адресов. Для пакетов, исходящих из сети V6, NAPT-PT будет транслировать IP-адрес источника, транспортный идентификатор источника и связанные с ними поля, такие, например, как контрольные суммы заголовков IP, TCP, UDP и ICMP. Транспортным идентификатором может быть либо один из портов TCP/UDP, или идентификатор (ID) запроса ICMP. Для входящих пакетов транслируются IP-адрес места назначения, транспортный идентификатор места назначения, а также контрольные суммы заголовков IP и транспортного заголовка.

Двунаправленный NAT-PT (Bi-directional NAT-PT) - при использовании этого механизма сеансы связи могут порождаться хостами из сети V4, а также хостами из сети V6. Адреса V6 сети связываются с V4 адресами статически или динамически когда в любом из направлений устанавливаются соединения. Предполагается, что пространство имен между хостами в сетях V4 и V6 (имеются в виду их полностью квалифицированные доменные имена) является насквозь уникальным. Хосты в области V4 обращаются к хостам в области V6, используя для разрешения адресов службу доменных имен DNS. Для упрощения отображения имен в адреса совместно с двунаправленным NAT-PT должен применяться шлюз прикладного уровня DNS-ALG. В частности DNS-ALG должен быть способным транслировать V6 адреса в запросах и ответах DNS в их связки с V4 адресами, и наоборот, когда DNS пакеты пересекают адресные области V6 и V4.

Работа основного NAT-PT

Механизм NAT-PT предоставляет простое решение, основанное на прозрачной маршрутизации и трансляции адресов и протоколов, позволяющее большому числу приложений в областях V6 и V4 взаимодействовать без внесения каких-либо изменений в эти приложения. Ниже с помощью рис. 1 [ ] проиллюстрирована работа традиционного NAT-PT и описана методика, с помощью которой через традиционный NAT-PT можно инициировать соединения из хоста в домене IPv6 к хосту в домене IPv4.

           [IPv6-B]-+
                    |                  +==============+
           [IPv6-A]-+-[NAT-PT]---------|  сеть IPv4   |--[IPv4-C]
                         |             +==============+
                  (пул V4 адресов)


           Рис.1 Организация связи из сети IPv6 в сеть IPv4

           Узел IPv6-A имеет IPv6-адрес -> FEDC:BA98::7654:3210
           Узел IPv6-B имеет IPv6-адрес -> FEDC:BA98::7654:3211
           Узел IPv4-C имеет IPv4-адрес -> 132.146.243.30

Далее предполагается, что NAT-PT владеет пулом адресов, охватывающих IPv4-подсеть 120.130.26/24. В принципе, V4-адреса из этого пула могут быть присвоены V6-адресам оконечных узлов V6 на условиях сохранения взаимно однозначного соответствия. В этом случае потребуется столько V4-адресов, сколько имеется оконечных узлов V6. Однако в общем случае сети V6 может выделяться меньше V4-адресов, чем существующее количество оконечных узлов V6, и поэтому, по крайней мере, для некоторых из них требуется динамическое распределение адресов.

Пусть, например, узел IPv6-A хочет взаимодействовать с узлом IPv4-C. Узел А создает пакет со следующими полями:

    Source Address, SA=FEDC:BA98::7654:3210 и
    Destination Address, DA = PREFIX::132.146.243.30

Примечание: В оконечном домене V6 префикс PREFIX::/96 объявляется с помощью NAT-PT, и пакеты, адресованные этому префиксу, будут маршрутизироваться на NAT-PT. Требуется только, чтобы заранее конфигурируемый PREFIX был бы маршрутизируемым в рамках оконечного домена IPv6, и это может быть любой маршрутизируемый префикс, который выберет администратор сети.

Этот пакет маршрутизируется через шлюз NAT-PT, на котором он транслируется в IPv4. Если исходящий пакет не является пакетом инициализации сеанса связи, NAT-PT должен уже хранить некоторое состояние о соответствующем сеансе, включающее присвоенный IPv4-адрес и другие параметры для трансляции. Если такого состояния не существует, пакет должен молча отбрасываться. Если пакет является пакетом инициализации сеанса связи, то NAT-PT локально распределяет адрес из своего пула адресов (например, 120.130.26.10), и пакет транслируется в IPv4. Параметры трансляции кэшируются на время сеанса, и отображение IPv6 на IPv4 запоминается NAT-PT. Результирующий IPv4-пакет имеет SA=120.130.26.10 и DA=132.146.243.30.

Любой возвращаемый трафик будет распознаваться NAT-PT, как принадлежащий тому же самому сеансу связи. Для трансляции пакетов NAT-PT будет использовать информацию о состоянии, и результирующие адреса будут равны SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Заметим, что этот пакет может теперь маршрутизироваться как обычный пакет внутри оконечной сети, работающей только по протоколу IPv6.

Работа NAPT-PT

Механизм NAPT-PT, аббревиатура которого означает "Трансляция сетевых адресных портов + трансляция протоколов", позволяет V6-узлам прозрачно взаимодействовать с V4-узлами, используя всего один V4-адрес. При этом порты TCP/UDP узлов V6 транслируются в порты TCP/UDP зарегистрированного V4-адреса. В то время как поддержка NAT-PT ограничивается TCP, UDP и другими типами мультиплексирующих порты приложений, NAPT-PT решает проблему, которая является свойственной NAT-PT. Дело в том, что когда исчерпается пул выделенных для целей трансляции V4-адресов, произойдет отказ NAT-PT. А именно, после того, как исчерпается пул адресов, ни один из V6-узлов больше не сможет открывать сеансы связи с внешним миром. NAPT-PT, с другой стороны, прежде чем не останется для присваивания TCP и UDP портов, позволит открыть максимально до 63K сеансов TCP и до 63K сеансов UDP.

С целью иллюстрации можно модифицировать пример, показанный на рис.1, предположив, что на пограничном маршрутизаторе (вместо NAT-PT) установлен NAPT-PT, и все V6-адреса могут отображаться на единственный V4-адрес 120.130.26.10. Пусть узел IPv6-A хочет организовать сеанс TCP с узлом IPv4-C. Для этого узел A создает пакет со следующими параметрами:

    Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 и
    Destination Address, DA = PREFIX::132.146.243.30, destination TCP port =23.

Когда этот пакет поступит в устройство NAPT-PT, NAPT-PT присвоит один из TCP-портов выделенного V4-адреса для трансляции кортежа (Source Address, Source TCP port) следующим образом:

    SA=120.130.26.10, source TCP port = 1025  и
    DA=132.146.243.30, destination TCP port = 23.

Возвращаемый трафик от узла 132.146.243.30, TCP port 23 будет распознан как принадлежащий тому же самому сеансу, и будет транслироваться обратно в V6 следующим образом:

    SA = PREFIX::132.146.243.30, source TCP port = 23;
    DA = FEDC:BA98::7654:3210 , destination TCP port = 3017

Следует отметить, что входящие сеансы NAPT-PT ограничиваются одним сервером на сервис, назначаемым с помощью статического отображения TCP/UDP портов. Например, в домене V6 узел [IPv6-A] на рис.1 может быть только HTTP-сервером (port 80).
Пусть узел [IPv4-C] посылает пакет:

    SA=132.146.243.30, source TCP port = 1025  и
    DA=120.130.26.10, destination TCP port = 80

Тогда NAPT-PT оттранслирует этот пакет в:

    SA=PREFIX::132.146.243.30, source TCP port = 1025
    DA=FEDC:BA98::7654:3210, destination TCP port = 80

Заметим, что в вышеприведенном примере все входящие сеансы, которые достигают NAPT-PT с портом места назначения равным 80, будут переадресованы на один и тот же узел [IPv6-A].

Работа двунаправленного NAT-PT: использование DNS-ALG для присваивания адресов

NAT-PT присваивает IPv4-адрес V6-узлу, когда NAT-PT определяет начало входящего или исходящего сеанса связи. Выполнение определения начала нового входящего сеанса отличается от выполнения определения начала новых исходящих сеансов. Однако для присваивания V6-узлам используется тот же самый пул V4-адресов, независимо от того, инициируется ли исходящий сеанс из узла V6, или входящий сеанс из узла V4.

Отображения IPv4 имен на адреса хранятся в DNS в виде записей типа "A". Отображения IPv6 имен на адреса в настоящее время хранятся в DNS в виде записей типа "AAAA". Кроме того, были определены записи типа "A6", но ко времени написания данного документа они еще не были полностью стандартизованы и развернуты. Однако в любом случае принцип работы DNS-ALG, описанный в данном разделе, остается тем же самым как для записей типа "AAAA", так и для записей типа "A6". Единственное отличие заключается в том, что разрешение имен с помощью записей типа "A6" может потребовать более одной пары взаимодействий "запрос-ответ". DNS-ALG должен в этом случае отследить все ответы в транзакции, перед тем как транслировать запись типа "A6" в запись типа "A".

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

Присваивание V4 адреса входящим соединениям (из V4 в V6)

         [DNS]--+
                |              [DNS]------[DNS]-------[DNS]
       [IPv6-B]-+                           |           |
                |                  +==============+     |
       [IPv6-A]-+----[NAT-PT]------|   сеть IPv4  |--[IPv4-C]
                        |          +==============+
                  (пул v4 адресов)


       Рис. 2. Организация связи из сети IPv4 в сеть IPv6

       Узел IPv6-A имеет IPv6 адрес -> FEDC:BA98::7654:3210
       Узел IPv6-B имеет IPv6 адрес -> FEDC:BA98::7654:3211
       Узел IPv4-C имеет IPv4 адрес -> 132.146.243.30

NAT-PT имеет пул адресов, охватывающих подсеть IPv4 120.130.26/24. Выше на рис. 2, когда резольвер имен узла C посылает запрос поиска имени для узла A, этот запрос направляется на сервер DNS в сети V6. Если NAT-PT находится на пограничном маршрутизаторе между сетями V4 и V6, то эта дейтаграмма запроса должна проходить через этот маршрутизатор. DNS-ALG на устройстве NAT-PT будет модифицировать DNS запросы для записей типа "A", идущие в домен V6 следующим образом (заметим, что TCP/UDP DNS пакет распознается по тому факту, что в нем номер порта источника или места назначения равен 53):
a) Для запросов Node Name to Node Address Query: Изменить тип запроса с "A" на "AAAA" или "A6".
b) Для запросов Node address to Node name query: Заменить строку "IN-ADDR.ARPA" строкой "IP6.INT". Заменить октеты адреса V4 (в обратном порядке) предшествующие строке "IN-ADDR.ARPA" соответствующими октетами адреса V6 в обратном порядке (если существует отображение).

В противоположном направлении, когда ответ DNS идет от DNS сервера в сети V6 к узлу V4, DNS-ALG снова перехватывает DNS пакет и делает следующее:
a) Транслирует DNS ответы для записей типа "AAAA" или "A6" в записи типа "A" (транслирует записи типа "A6" только когда имя полностью разрешено)
b) Заменяет V6 адрес, разрешенный V6 DNS, на V4 адрес, присвоенный изнутри маршрутизатором NAT-PT.

Если V4 адрес ранее этому узлу V6 не назначался, то NAT-PT в этот момент как раз его и присвоит. Например, пусть узел IPv4-C пытается инициировать сеанс связи с узлом IPv6-A посредством поиска имени (записи типа "A") для узла A. Запрос имени направляется в локальный DNS, и оттуда передается DNS серверу в сети IPv6. DNS-ALG перехватывает его и транслирует запрос типа "A" в запрос типа "AAAA" или "A6" и затем пересылает его DNS серверу сети IPv6, который отвечает следующим образом (для удобства в примере используются записи типа "AAAA"):

    Node-A    AAAA     FEDC:BA98::7654:3210,

Эта запись возвращается DNS сервером, перехватывается и транслируется DNS-ALG в следующий вид:

    Node-A     A      120.130.26.1

DNS-ALG фиксирует также отображение между адресами FEDC:BA98::7654:3210 и 120.130.26.1 в NAT-PT. Запись типа "A" затем возвращается узлу C. Теперь узел C может инициировать сеанс следующим образом:

    SA=132.146.243.30, source TCP port = 1025  и
    DA=120.130.26.1, destination TCP port = 80

Пакет будет возвращен в NAT-PT, который, поскольку он уже хранит отображение между FEDC:BA98::7654:3210 и 120.130.26.1 может транслировать пакет в следующий вид:

    SA=PREFIX::132.146.243.30, source TCP port = 1025
    DA=FEDC:BA98::7654:3210, destination TCP port = 80

Теперь связь может продолжаться обычным образом.

Значения TTL на всех DNS записях о ресурсах (RR), передающиеся через NAT-PT, должны быть установлены в 0, так чтобы DNS серверы/клиенты не кэшировали временно присвоенные RR. Заметим, однако, что из-за некоторых реализаций DNS клиентов, содержащих ошибки, значение 1 может в некоторых случаях работать лучше. Значения TTL должны оставаться неизменными для статически отображаемых адресов.

Отображения адресов для входящих сеансов, как описано выше, являются объектом атак, вызывающих отказы в обслуживании, поскольку к узлам, находящимся в сети V6, можно делать множество запросов, которые заставят DNS-ALG отобразить все V4 адреса в NAT-PT и тем самым блокировать законные входящие сеансы. Таким образом, чтобы минимизировать эффект от атак, вызывающих отказы в обслуживании, адресные отображения для входящих сеансов должны обрываться по тайм-ауту. Дополнительно, один из IPv4 адресов (используя NAPT-PT) может быть зарезервирован для исходящих сеансов только для того, чтобы минимизировать эффект таких атак на исходящие сеансы связи.

Присваивание V4 адреса для исходящих сеансов связи (из V6 в V4)

Узлы V6 узнают адреса узлов V4 у DNS сервера в домене V4 или DNS сервера, внутреннего для сети V6. RFC 2766 рекомендует, чтобы внутренние для V6 домена DNS серверы поддерживали отображения имен на IPv6 адреса для внутренних узлов и, возможно, кэшировали отображения для некоторых внешних узлов. В случае, когда DNS сервер в домене V6 содержит отображения для внешних V4-узлов, DNS запросы не будут покидать домен V6, и это будет устранять необходимость вмешательства DNS-ALG. В противном случае запросы будут уходить из домена V6 и являются объектом вмешательства DNS-ALG. RFC 2766 рекомендует внешним DNS серверам в домене V4 кэшировать только отображения имен для внешних узлов (т.е. V4-узлов). Передачи зон через границы IPv4 - IPv6 строго не рекомендуются.

В случае NAPT-PT, при обнаружении каждого нового исходящего сеанса связи для зарегистрированного V4 адреса присваивается порт источника TCP/UDP. Как уже отмечалось, узел V6, которому необходимо взаимодействовать с узлом V4, должен использовать специальный префикс (PREFIX::/96) перед IPv4 адресом узла V4. Описанный выше способ позволяет использовать этот PREFIX без какого-либо конфигурирования узлов. Приведем другой пример на рис. 2. Пусть узел A хочет установить сеанс связи с узлом C. Для этого узел A начинает работу, выполняя поиск имени (запись "AAAA" или "A6") для узла C.

Поскольку узел C может иметь IPv6 и/или IPv4 адреса, DNS-ALG на устройстве NAT-PT пересылает без изменений первоначальный запрос типа "AAAA"/"A6" внешней системе DNS, а также запрос типа "A" для того же узла. Если для приемника (места назначения) существует запись типа "AAAA"/"A6", то она будет возвращена в NAT-PT, который перешлет ее, также без изменений, хосту-первоисточнику. Если для узла C имеется запись типа "A", то ответ также возвращается в NAT-PT. Тогда DNS-ALG транслирует ответ, добавляя соответствующий PREFIX, и пересылает его устройству-первоисточнику с любым IPv6 адресом, который мог быть известен. Так, если был ответ:

 NodeC    A     132.146.243.30, то он транслируется в
 NodeC   AAAA   PREFIX::132.146.243.30 или в
 NodeC    A6    PREFIX::132.146.243.30

Теперь узел A может использовать этот адрес подобно любому другому IPv6-адресу, и V6 DNS-сервер может даже кэшировать его до тех пор, пока не изменится PREFIX. Здесь существует проблема: как DNS-сервер в оконечном домене V6 разговаривает с доменом V4, находящимся вне домена V6. Вспомним, что здесь отсутствуют узлы с двойным стеком. Внешний V4 DNS-сервер должен указывать на V4 адрес, который является частью пула V4 адресов, доступных NAT-PT. NAT-PT хранит взаимно однозначное соответствие между этим V4 адресом и V6 адресом внутреннего V6 DNS-сервера. В другом направлении V6 DNS-сервер указывает на V6 адрес, сформированный из IPv4 адреса внешних V4 DNS-серверов и префикса (PREFIX::/96), который служит признаком узлов, работающих не по протоколу IPv6. Этот механизм может быть просто расширен, чтобы организовать вторичные серверы DNS.


Трансляция протоколов

В этой своей части NAT-PT основывается на алгоритме, определённом в стандарте на бесконтекстную трансляцию SIIT (RFC 2765). Мы не будем приводить его здесь, дабы не останавливаться на множестве технических деталей, остановимся лишь на отличиях протокольной трансляции NAT-PT от этого алгоритма, обусловленных применением контекстного метода трансляции. Детальное описание механизма трансляции протоколов IPv4/IPv6 можно найти в RFC 2765 или статье [ ].

Трансляция заголовков IPv4 в заголовки IPv6

Она выполняется точно так же, как и в SIIT, за исключением следующих полей:

Source Address:
Младшие 32 бита представляют собой IPv4 source address. Старшие 96 бит представляют собой выделенный PREFIX для всех взаимодействий с сетью V4. Адреса, использующие этот PREFIX, будут маршрутизироваться на шлюз NAT-PT (PREFIX::/96)

Destination Address:
NAT-PT запоминает отображение между IPv4 destination address и адресом IPv6 узла назначения. IPv4 destination address заменяется адресом IPv6, хранящимся в этом отображении.

Трансляция заголовков IPv6 в заголовки IPv4

Она выполняется точно так же, как и в SIIT, за исключением поля Source Address, которое должно определяться следующим образом:

Source Address:
NAT-PT запоминает отображение между IPv6 source address и адресом IPv4, взятым из пула доступных адресов IPv4. IPv6 source address заменяется IPv4 адресом, хранящимся в этом отображении.

Destination Address:
Транслируемые пакеты IPv6 имеют destination address в виде PREFIX::IPv4/96. Таким образом, младшие 32 бита IPv6 destination address копируются в поле IPv4 destination address.


Коррекция контрольных сумм TCP/UDP/ICMP

NAT-PT запоминает отображение между IPv6 адресом и IPv4 адресом, взятым из пула доступных адресов IPv4. Это отображение используется при трансляции пакетов, которые проходят через NAT-PT.

Коррекция контрольной суммы TCP/UDP/ICMP из IPv4 в IPv6

Контрольные суммы UDP, если они имеют ненулевое значение, и контрольная сумма TCP должны быть пересчитаны, чтобы отразить замену адреса V4 на адрес V6. Алгоритм инкрементальной коррекции контрольной суммы может быть заимствован из [NAT]. В случае NAPT-PT контрольная сумма TCP/UDP должна быть скорректирована так, чтобы учесть изменения адресов и портов TCP/UDP, происходящие при переходе из V4 в V6. Когда контрольная сумма V4 UDP пакета установлена в ноль, NAT-PT должен определить цельность контрольной суммы для V6-транслированного UDP пакета. Если V4 UDP пакет с контрольной суммой равной нулю прибывает в фрагментах, то NAT-PT должен дождаться всех фрагментов до тех пор, пока они не смогут быть собраны в один нефрагментированный пакет, и определить контрольную сумму перед тем, как переслать транслированный V6 UDP пакет.

ICMPv6, в отличие от ICMPv4, во время вычисления контрольной суммы использует псевдозаголовок, точно так же, как UDP и TCP. В результате, когда вычисляется контрольная сумма заголовка ICMPv6 [SIIT], эту контрольную сумму необходимо скорректировать, чтобы учесть дополнительный псевдозаголовок. Заметим, что может потребоваться коррекция контрольной суммы из-за изменений в адресах источника и места назначения (и изменений в идентификаторах TCP/UDP/ICMP в случае NAPT-PT) в данных, передаваемых внутри ICMP.

Коррекция контрольной суммы TCP/UDP/ICMP из IPv6 в IPv4

Контрольные суммы TCP и UDP должны быть заново вычислены, чтобы отразить замену адресов V6 на адреса V4. Инкрементный алгоритм коррекции контрольной суммы может быть заимствован из [NAT]. В случае NAPT-PT контрольные суммы TCP/UDP должны быть скорректированы, чтобы учесть изменения в адресах и портах TCP/UDP при переходе от V6 адресов к V4 адресам. Для UDP пакетов контрольная сумма может быть просто заменена на нулевую.

Вычисление контрольной суммы для заголовка V4 ICMP должно быть получено из заголовка V6 ICMP путем выполнения алгоритма коррекции контрольной суммы [NAT] для того, чтобы из вычисления убрать псевдозаголовок V6. Заметим, что коррекция должна дополнительно учитывать изменения контрольной суммы из-за изменений адресов источника и места назначения (и транспортных портов в случае NAPT-PT), сделанных в данных, переносимых внутри ICMP.


Ограничения NAT-PT

Все ограничения, присущие механизму трансляции сетевых адресов (NAT), в той же мере присущи и NAT-PT. Здесь подробно приведены наиболее важные из них, а также некоторые ограничения, присущие только NAT-PT.

Ограничения топологии

Требуется, чтобы все запросы и ответы, относящиеся к одному сеансу связи, маршрутизировались через один и тот же NAT-PT маршрутизатор. Одним из способов обеспечения этого требования может быть организация NAT-PT на пограничном маршрутизаторе, который является уникальным для оконечного IPv6 домена, когда все IP пакеты либо порождаются из этого домена, либо этот домен является их местом назначения. Это общая проблема, связанная с NAT, и она полностью описана в [NAT-TERM]. Заметим, что это ограничение не распространяется на пакеты, которые порождаются из узлов с двойным стеком или направляются на узлы с двойным стеком и не требуют трансляции адресов. Это справедливо, поскольку в устройстве с двойным стеком IPv4 адреса, заключенные в V6 адрес, могут быть идентифицированы по формату адреса PREFIX::x.y.z.w, и маршрутизатор с двойным стеком может соответствующим образом маршрутизировать пакет между V4 и узлами с двойным стеком без отслеживания информации о состоянии. Это ограничение также не должно влиять на взаимодействие между IPv6 и IPv6, и в действительности трансляцию нужно использовать только когда не возможно применение никаких других средств связи. Например, NAT-PT может также иметь естественное IPv6 соединение и/или некоторый вид туннелированного IPv6 соединения. Оба указанных выше типа соединения должны быть предпочтительными по сравнению с трансляцией, если они возможны, поскольку NAT-PT представляет собой только инструмент, который используется для поддержки перехода к естественным взаимодействиям между IPv6 и IPv6.

Ограничения трансляции протоколов

Некоторые поля IPv4 в IPv6 имеют измененный смысл, и трансляция оказывается не прямолинейной. Например, семантика и синтаксис заголовков расширения в IPv6 существенно изменились. Детали трансляции протоколов IPv4 в IPv6 можно найти в [SIIT].

Эффект трансляции адресов

Поскольку NAT-PT выполняет трансляцию адресов, приложения, которые передают IP адрес на более высоких уровнях, не будут работать. В этом случае, чтобы обеспечить поддержку таким приложениям, необходимо встроить шлюз прикладного уровня (ALG). Это общая проблема NAT, и она полностью описана в [NAT-TERM].

Отсутствие сквозной защиты

Одним из наиболее важных ограничений предложения по NAT-PT является тот факт, что не возможно обеспечить сквозную защиту на сетевом уровне. Кроме того, может оказаться невозможной защита на транспортном и прикладном уровнях для тех приложений, которые передают IP адреса на прикладной уровень. Это естественное ограничение функции трансляции сетевых адресов. Независимо от NAT-PT, сквозная защита IPSec не возможна через различные адресные области. Два оконечных узла, которым необходима защита на сетевом уровне IPSec, должны поддерживать либо IPv4, либо IPv6.

Трансляция DNS и DNSSEC

Схема, описанная выше, включает в себя трансляцию сообщений DNS. Ясно, что эта схема не может разворачиваться в комбинации с защищенным DNS. Т.е. полномочный сервер имен DNS в домене V6 не может подписывать ответы на запросы, которые порождаются из сети V4. В результате оконечный узел V4, который требует, чтобы DNS ответы были подписаны, будет забраковывать ответы, которые были изменены NAT-PT. Однако за указанное выше ограничение вынуждены расплачиваться только серверы в домене V6, которые должны быть доступны из сети V4, поскольку оконечные узлы V4 могут не обращаться к V6 серверам из-за того, что DNS запросы не подписываются. Заметим также, что передачи зон между серверами DNSSEC внутри одной и той же сети V6 не затрагиваются. Очевидно, что при развертывании DNSSEC на DNS-серверах и резольверах оконечных хостов, предложенная в данном документе схема не будет работать.


Область примененя

NAT-PT может быть полезным инструментом обеспечения совместимости на границе оконечной сети, которая развернута как сеть, основанная только на протоколе IPv6, когда она соединяется с Internet, которая, в свою очередь, либо полностью базируется только на V4, либо представляет собой комбинацию V4 и V6.

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

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


Реализация

Последняя версия: natpt.tar.gz

В настоящий момент авторами реализован механизм основного NAT-PT в виде псевдо-сетевого устройства в операционной системе FreeBSD с KAME IPv6 стеком. Основное тестирование проводилось на базе FreeBSD 4.4 с установленным SNAP-20011112. Такой метод реализации был предпочтен стандартному встраиванию в ядро в виде сетевого фильтра из-за его очевидных преимуществ. Во-первых, реализация транслятора в виде драйвера (псевдо)сетевого интерфейса позволяет существенно упростить сам транслятор. Так, например, IP/ICMP транслятор, так же как и обычный маршрутизатор, должен отслеживать значение полей TTL и Hop Limit протоколов IPv4 и IPv6, соответственно. Входящие пакеты, у которых эти поля нулевые, транслятор должен сбрасывать и отсылать отправителю ICMP сообщение Time Exceeded. При реализации транслятора в виде драйвера сетевого интерфейса задача проверки этих полей ложится на сам стек IPv4 или IPv6. Точно так же, все необходимые проверки, которые должен выполнять маршрутизатор, а именно: проверка контрольных сумм заголовка IPv4, проверка соответствия размера пакета информации о размере, содержащейся в заголовке IP, проверка превышения длины пакета размера MTU на исходящем сетевом интерфейсе и т.д. - осуществляются самими стеками IPv4 и IPv6, а не транслятором. Во-вторых, не требуется собирать новое, специализированное ядро системы. Драйвер может быть включен в работающую систему или выключен из нее, что называется "на ходу". Помимо самого драйвера было разработано приложение, позволяющее менять параметры работы NAT-PT без прерывания текущих соединений.

Для того, чтобы NAT-PT заработал, необходимо:
1. Cделать хост с установленным NAT-PT IPv6 и IPv4 маршрутизатором. Для этого нужно выставить следующие значения системных переменных:

   o  net.inet.ip.forwarding = 1 
   o  net.inet6.ip6.forwarding = 1 
   o  net.inet6.ip6.rtadv_accept = 0
2. Настроить внутри IPv6 сети маршрутизацию пакетов PREFIX:: на этот хост. На самом хосте прописать маршрутизацию таких пакетов на ntpt интерфейс.
3. Выделить пул глобальных IPv4 адресов для трансляции и настроить их маршрутизацию внутри IPv4 сети на данный хост, на самом хосте на ntpt интерфейс. Для упрощения конфигурации можно осуществить привязку нового пула для NAT-PT и настройку IPv4 маршрутизации внутри хоста путем смены IPv4 адреса ntpt интерфейса. При этом NAT-PT выделит сетевую часть привязанного к интерфейсу адреса и будет использовать её как пул для динамического выделения глобальных IPv4 адресов.

По своей функциональности транслятору приходится иметь дело с представлением сетевых данных в ядре операционной системы, на основе которой данный механизм разрабатывается. Основное различие реализаций на разных платформах определяется именно различием в представлении сетевых данных на данной платформе. В системах на базе BSD для этой цели используются связанные списки буферов фиксированного размера - так называемых m-буферов. Поэтому нам показалась логичной следующая процедура обработки сетевых заголовков: из приходящего пакета вычленяются все необходимые для трансляции данные заменяемого заголовка, затем он удаляется, выделяется память под новый заголовок, который затем заполняется в соответствии с правилами трансляции. При выделении памяти ядро может выделить как новый буфер, так и место в старом, если его достаточно. Такая архитектура сетевых буферов позволяет сократить накладные расходы памяти и ускорить её выделение и освобождение, однако, она не позволяет корректно пересчитывать контрольные суммы из-за непоследовательного расположения данных и перед этой процедурой приходится перемещать все необходимые заголовки в один буфер.

Непосредственно функциональность NAT-PT реализована с помощью 2 списков записей о текущих привязках адресов. Первый список используется для простой трансляции, при этом статические записи в нём имеют специальный признак - нулевое время прохождения пакета. Второй список аналогичным образом используется для NAPT-PT. Использование двух разных списков обусловлено различием в необходимых для хранения данных в этих случаях. Если в NAT-PT достаточно хранить IPv6 и IPv4 адреса и время прохождения последнего пакета, соответствующего данной записи, то для NAPT-PT необходимо хранить ещё и соответствие портов.

В отличие от механизма SIIT, NAT-PT особым образом обрабатывает TCP соединения. Для этого протокола установлены свои собственные тайм-ауты и особым образом определены термины "инициализация соединения" и "конец соединения". По сути, для обработки ТСР пакетов пришлось написать код, по размерам сопоставимый со всем остальным кодом.

Наша реализация NAT-PT в соответствии со стандартом обеспечивает как динамическое, так и статическое выделение адресов. Помимо этого, на каждом из адресов может быть включен режим трансляции портов. По умолчанию такой режим используется только на последнем неиспользованном IPv4 адресе в пуле во избежание отказа NAT-PT. Параметры кэширующих записей, такие как максимальное время жизни записи, время жизни TCP записи, нижняя граница используемых для трансляции портов также настраиваются, причём без обрыва текущих соединений и перезагрузки всех записей. Работа продолжается и в планах авторов реализовать двунаправленный механизм.


Литература

1. G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000
2. Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
3. Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
4. Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
5. Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
6. S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification" , RFC 2460, December 1998.
7. S. Deering, R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
8. R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
9. S. Deering, A. Conta , "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
10. J. Postel, "Internet Protocol", RFC 791, September 1981.
11. J. Postel, "Internet Control Message Protocol", RFC 792, September 1981.
12. J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
13. J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
14. K. Nichols, S. Blake, F. Baker, and D. L. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
15. Ломака А.А., Шнитман В.З., "Обеспечение совместимости протоколов IPv4 и IPv6: бесконтекстный IP/ICMP транслятор для среды Linux", Сб. трудов ИСП РАН, М, 2000
16. Шнитман В.З.,"Проблемы организации взаимодействия сетей, построенных на базе протоколов IPv4 и IPv6", Сб. тезисов докладов Всероссийской научной конференции "Научный сервис в сети ИНТЕРНЕТ", г.Новороссийск, 2000г., стр. 16-17.