Переходные технологии

Последний большой модуль посвящен переходным механизмам (Transition Technologies). Тема очень полезная и нужная: как сделать так, чтобы связь по IPv6 или IPv4 работала даже в случае, если между сегментами сети используется другой протокол. Как передать IPv6-пакет поверх IPv4-сети? Или наоборот — как передать IPv4-пакет поверх IPv6-сети?

Переходные технологии для передачи IPv4 поверх IPv6 в современном мире даже более важны, чем старые механизмы передачи IPv6 поверх IPv4.

Зачем нужны переходные технологии

Не во всех сетях есть поддержка и IPv4, и IPv6. IPv4 есть почти везде в клиентских сетях, однако IPv6 у клиентов присутствует не всегда. У провайдеров тоже не у всех IPv6 реализован в полной мере — бывает, что провайдер в свое время построил IPv4-сеть и не собирается ничего менять.

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

Переходные технологии применяются в нескольких сценариях:

• Клиент использует их самостоятельно, когда провайдер не предоставляет IPv6
• Провайдер применяет их внутри своей сети, когда часть оборудования не поддерживает IPv6
• Провайдер передает клиентские IPv4-пакеты поверх внутренней IPv6-сети

При этом оба протокола прекрасно сосуществуют — нет задачи полностью отказываться от IPv4. Приложения, работающие только по IPv4, до сих пор есть, и около 82% сайтов из топ-1000 не работают по IPv6.

Dual Stack

Самый простой вариант — поднять оба протокола на всех узлах и роутерах. Dual Stack означает, что IPv4 и IPv6 работают параллельно: отдельные таблицы маршрутизации, отдельная обработка пакетов.

Это самый простой для понимания, но самый тяжелый для администрирования подход:

• Всю работу нужно делать дважды: отдельно настраивать IPv4, отдельно IPv6
• Политики безопасности нужно реализовывать два раза
• В IPv4 узлы часто сидят за NAT, что обеспечивает определенную защиту. В IPv6 NAT нет — любой узел с Global Unicast-адресом может быть доступен снаружи
• На роутерах количество настроек возрастает порой даже не вдвое

Безопасность при Dual Stack

Если вы используете IPv4 с NAT, целый класс атак снаружи отсекается автоматически. Но если вы добавляете IPv6, где NAT нет, то на каждом узле обязательно нужно прописывать полный набор политик безопасности. Не забывайте: если на роутере Cisco на Line VTY разрешен telnet, подключиться можно не только по IPv4, но и по IPv6. Если вы ограничили доступ по IPv4 access-листом, нужен отдельный access-лист для IPv6.

Тенденция современных провайдеров

У современных провайдеров есть четкая тенденция: IPv6 передается нативно, а IPv4 — с помощью переходных технологий. Есть и провайдеры старой школы, у которых IPv4 основной протокол, а IPv6 гоняется поверх него.

IPv4-Mapped адреса и работа TCP в Dual Stack

Когда операционная система поддерживает Dual Stack, реализация протокола TCP, как правило, одна — для IPv6. Даже когда нужно отправить пакет на IPv4-узел, TCP формирует IPv6-заголовок, а затем он переделывается в IPv4.

Для этого используются IPv4-Mapped адреса — адреса вида:

::ffff:<IPv4-адрес>

Структура: 80 нулевых бит + 16 единичных бит (ffff) + 32 бита IPv4-адреса.

Например, IPv4-адрес 192.0.2.1 записывается как ::ffff:192.0.2.1 или ::ffff:c000:0201.

Когда узел хочет отправить пакет на IPv4-адрес, он формирует IPv6-пакет с IPv4-Mapped адресом получателя. Сетевой обработчик IPv6 видит префикс ::ffff: и понимает, что нужно сделать из IPv6-пакета IPv4 и отдать его на обработку IPv4. Входящие IPv4-пакеты проходят обратное преобразование.

Благодаря этому не нужно реализовывать два отдельных TCP — один для IPv4, другой для IPv6. Если в выводе netstat вы видите адреса вида ::ffff:<IPv4>, это признак того, что IPv6 является основным протоколом в системе, а IPv4 — на подхвате.

Важно: IPv4-Mapped адреса не маршрутизируемые. Их можно использовать только при Dual Stack для отправки псевдо-IPv6-пакетов по IPv4-среде.

Туннелирование

Если нужно передать пакет одного протокола через сеть другого протокола, используется туннелирование. Есть два основных варианта:

Прямое вложение (IP-in-IP)

Один IP-пакет вкладывается непосредственно в другой без дополнительных заголовков:

Вложение	Код протокола / Next Header	RFC
IPv6 в IPv4 (6in4)	Protocol 41	RFC 4213
IPv4 в IPv6 (4in6)	Next Header 4	RFC 2473
IPv6 в IPv6	Next Header 41	—

Накладные расходы — только заголовок внешнего протокола (20 байт для IPv4, 40 байт для IPv6).

GRE (Generic Routing Encapsulation)

Внутрь GRE можно положить что угодно: кадры Ethernet, IPv4, IPv6. Код протокола — 47. GRE поддерживает мультикаст и другие полезные функции, но имеет дополнительные накладные расходы в виде заголовка GRE (~4 байта).

Статические туннели

Самый простой вариант туннелирования — статический туннель между двумя роутерами. Например, два сайта с IPv6 связаны через IPv4-сеть:

[IPv6-сеть A] — [Роутер A] ===== IPv4-сеть ===== [Роутер B] — [IPv6-сеть B]

Роутер A получает IPv6-пакет, оборачивает его IPv4-заголовком (6in4 или GRE) и отправляет на IPv4-адрес роутера B. Роутер B раскрывает пакет, извлекает IPv6 и маршрутизирует по таблице IPv6.

Ограничения статических туннелей

При тысяче сайтов нужно строить туннели по схеме «каждый с каждым» — около миллиона соседств.

• Даже при схеме hub-and-spoke на центральном роутере нужно прописать тысячу соседств
• Провайдер с 100 тысячами клиентов не может прописать столько туннельных интерфейсов
• Для работы туннеля оба конца должны знать IPv4-адреса друг друга

Туннельные брокеры

Если ваш провайдер не предоставляет IPv6, можно воспользоваться туннельным брокером — сервисом, который создает статический туннель для вас. Пример — Hurricane Electric (he.net). Вы регистрируетесь, указываете свой публичный IPv4-адрес, брокер выделяет вам IPv6-сетку и анонсирует ее в BGP. Все IPv6-пакеты для вас приходят к брокеру, перепаковываются в IPv4 и доставляются вам.

Проблема работы через NAT

Ни у 6in4 (протокол 41), ни у GRE (протокол 47) нет номеров портов. Поэтому оба варианта плохо работают за NAT — требуется публичный IPv4-адрес, желательно статический. Большинство провайдеров не реализуют ALG для этих протоколов, и инкапсуляция через NAT просто не проходит.

Динамические туннели: IPv6 поверх IPv4

Для построения динамических туннелей без предварительной настройки каждого соседства существует несколько технологий.

6to4

6to4 — самый простой механизм динамического туннелирования. Использует инкапсуляцию 6in4 (код протокола 41).

Важно различать:

• 6in4 — механизм вкладывания IPv6-пакетов в IPv4
• 6to4 — механизм построения динамических туннелей, использующий 6in4

Принцип работы

Адрес получателя IPv4-пакета — 192.88.99.1 (anycast-адрес 6to4 Relay). IPv6-адреса используют префикс 2002::/16, после которого идет 32-битный IPv4-адрес отправителя в шестнадцатеричной записи:

2002:<IPv4 в hex>::/48

Например, для IPv4-адреса 192.0.2.1 (hex: c000:0201):

2002:c000:0201::/48

Каждый узел с публичным IPv4-адресом получает в свое распоряжение целую /48 сетку.

Маршрутизация обратного трафика

Все 6to4 Relay анонсируют сетку 2002::/16 в IPv6-интернет. Обратный пакет приходит на ближайший relay (не обязательно тот же, через который ушел оригинальный пакет). Relay извлекает IPv4-адрес из IPv6-адреса получателя и отправляет пакет в IPv4-сети.

Проблема: неконтролируемый обратный трафик

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

Статус: технология устаревшая (deprecated).

6RD (Rapid Deployment)

6RD — развитие 6to4, решающее проблему неконтролируемого обратного трафика. Провайдер размещает 6RD Relay в своей сети и контролирует обе стороны трафика.

Принцип работы

1. Провайдер выделяет клиентам IPv6-адреса из своего блока (например, 2001:db8::/32)
2. IPv4-адрес клиента алгоритмически кодируется в IPv6-адресе (можно использовать не все 32 бита, а только значимую часть)
3. Клиенты отправляют 6in4-пакеты на известный IPv4-адрес 6RD Relay провайдера
4. Relay анонсирует IPv6-префикс провайдера в интернет
5. Обратный трафик приходит на Relay провайдера, а не на произвольный чужой relay

Преимущества

Провайдер контролирует доставку трафика в обе стороны.

• Можно применять Quality of Service
• Задержка минимальна — пакеты не выходят за пределы провайдерской сети
• Не требуется менять IPv4-инфраструктуру — поверх нее просто гоняются 6in4-вложения

Историческая справка

Французский провайдер Free стал пионером 6RD и предоставил доступ к IPv6 почти всем своим клиентам. Благодаря этому Франция была одним из лидеров по развитию IPv6.

Статус: технология устаревшая, но сыграла важную роль.

Teredo

Teredo — технология, названная в честь корабельного червя (моллюска Teredo navalis), который проковыривал дырки в деревянных судах. Аналогично, протокол Teredo «проковыривает дырку» в IPv4-интернете для доступа к IPv6.

Принцип работы

Teredo использует UDP (порт 3544) для инкапсуляции IPv6-пакетов в IPv4. Благодаря UDP протокол проходит через NAT.

1. Клиент устанавливает сессию с Teredo-сервером
2. Сервер узнает публичный IPv4-адрес и порт клиента (с учетом NAT)
3. Клиент получает IPv6-адрес из префикса 2001:0000::/32, в котором закодированы:
   • IPv4-адрес Teredo-сервера
   • Номер порта клиента (в обфусцированном виде)
   • IPv4-адрес клиента (в обфусцированном виде)

Teredo-сервер анонсирует /64 сетку. Получив обратный IPv6-пакет, сервер алгоритмически извлекает IPv4-адрес и порт клиента из IPv6-адреса получателя.

Проблемы безопасности

В Windows Teredo встроен и по умолчанию активен — машина, включенная в IPv4-сеть, автоматически получает IPv6-адрес.

• Каждый узел независимо строит сессию с сервером — нельзя управлять централизованно
• В корпоративной сети роутер видит только IPv4-пакеты и не может инспектировать IPv6-содержимое
• Создает неконтролируемый доступ к IPv6-интернету в обход корпоративных политик безопасности
• Зная IPv4-адрес и Teredo-сервер, атакующий может вычислить Teredo-адрес узла

Приоритет в Windows

Если узел доступен и по IPv4, и по IPv6, Windows при использовании Teredo предпочитает IPv4 (A-записи), а не IPv6 (AAAA-записи). Это намеренное решение — Teredo считается ущербным транспортом.

Рекомендация: в корпоративных сетях блокируйте UDP-порт 3544 и отключайте Teredo. Лучше предоставить нативный IPv6.

Статус: технология устаревшая.

6over4 и ISATAP

Следующая группа протоколов предназначена для связи разрозненных IPv6-сайтов через IPv4-сеть.

6over4

6over4 — механизм, создающий виртуальный IPv6-интерфейс поверх IPv4-сети. Link-local адреса на таком интерфейсе формируются как fe80::<IPv4-адрес>. Для обнаружения соседей (Neighbor Discovery) требуется мультикаст в IPv4-сети.

Статус: устарел на этапе рождения, поскольку мультикаст в интернете практически недоступен.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)

ISATAP — живая замена 6over4. Работает как NBMA (Non-Broadcast Multiple Access) среда, не требуя мультикаста.

Link-local адреса используют формат:

fe80::5efe:<IPv4-адрес>

Для обнаружения соседей вместо мультикаста используется DNS:

1. Узел резолвит имя isatap.<доменный-суффикс>
2. Получает список A-записей — PRL (Potential Router List)
3. Отправляет Router Solicitation юникастом каждому потенциальному соседу
4. Живые соседи отвечают Router Advertisement

Преимущество ISATAP — возможность передавать приватные IPv6-адреса (ULA, fd00::/8) между сайтами через IPv4-интернет.

Статус: формально живой, но практически невостребован — в современных сетях все чаще используется нативный IPv6.

Трансляция: IPv6 в IPv4

Все описанные выше технологии решали задачу доступа к IPv6 через IPv4. Обратная задача — когда у клиента есть только IPv6, но нужен доступ к IPv4-ресурсам — решается механизмами трансляции (NAT).

NAT-PT (устаревший)

NAT-PT (Network Address and Port Translation — Protocol Translation) — устаревший механизм трансляции IPv6 в IPv4.

Терминология (в стиле Cisco)

Термин	Описание
Inside Local	Оригинальный IPv6-адрес отправителя (до трансляции)
Inside Global	IPv4-адрес, в который перебивается адрес отправителя
Outside Local	IPv6-адрес получателя (до трансляции)
Outside Global	Оригинальный IPv4-адрес получателя

Принцип работы

1. Клиент IPv6 хочет подключиться к IPv4-узлу
2. Отправляет DNS-запрос (AAAA) через NAT-PT роутер
3. Роутер с DNS-ALG перехватывает запрос, подменяет его на A-запрос
4. Получив ответ (IPv4-адрес), роутер конструирует синтетический IPv6-адрес с определенным префиксом (например, fdff::<IPv4>)
5. Возвращает клиенту AAAA-запись с этим адресом
6. Клиент отправляет пакеты на этот IPv6-адрес, роутер транслирует их в IPv4

Проблемы

Требует DNS-ALG на роутере, что часто приводит к некорректным ответам.

• Плохо работает при двойном NAT
• Не поддерживает DNSSEC
• Ограниченный пул IPv4-адресов при трансляции с портами
• Плохо масштабируется

Статус: устаревший, не рекомендуется к использованию.

NAT64 + DNS64

NAT64 — современная замена NAT-PT, существенно более стабильная и функциональная.

DNS64

Ключевое отличие — DNS-функциональность вынесена на отдельный сервер DNS64, который:

1. Получает AAAA-запрос от IPv6-клиента
2. Если AAAA-запись существует — возвращает ее как есть
3. Если AAAA-записи нет — запрашивает A-запись и конструирует синтетический IPv6-адрес

Well-Known Prefix (WKP)

NAT64 использует well-known prefix (WKP):

64:ff9b::/96

К этому 96-битному префиксу приклеивается 32-битный IPv4-адрес. Полученный адрес называется IPv4-Embedded Address.

Замечательное свойство WKP: он нейтрален с точки зрения Internet Checksum. При замене IPv6-заголовка на IPv4 чек-суммы TCP и UDP не нужно пересчитывать — они сохраняются автоматически.

Помимо WKP, можно использовать собственные префиксы (/32, /40, /48, /56) — это полезно при двойном NAT, когда нужны глобальные юникастовые адреса.

Пример работы NAT64 + DNS64

1. Клиент IPv6 → DNS64: "AAAA для example.com?"
2. DNS64 → интернет: "AAAA для example.com?" → нет ответа
3. DNS64 → интернет: "A для example.com?" → 203.0.113.1
4. DNS64 → Клиент: "AAAA: 64:ff9b::203.0.113.1"
5. Клиент → NAT64: TCP SYN на 64:ff9b::cb00:7101, порт 80
6. NAT64 транслирует в IPv4: TCP SYN на 203.0.113.1, порт 80

Преимущества NAT64 над NAT-PT

В отличие от NAT-PT, NAT64 не требует DNS-ALG на роутере.

• DNS64 корректно работает с нативными AAAA-записями
• Теоретически поддерживает DNSSEC
• Стабильнее с peer-to-peer приложениями
• Лучше работает за двойным NAT

Обнаружение DNS64

Для определения, используется ли DNS64, можно резолвить специальное имя:

ipv4only.arpa

У этого домена есть только A-записи. Если в ответ приходит AAAA — значит, DNS64 активен.

Stateless vs Stateful NAT64

Характеристика	Stateless	Stateful
Соответствие адресов	1:1 (IPv6 ↔ IPv4)	N:1 (много IPv6 → один IPv4)
Таблица трансляции	Не нужна	Требуется
Направление	Двунаправленный	Только изнутри наружу
Экономия адресов	Нет	Да
Скорость	Высокая	Ниже

Stateless — быстро и эффективно, но требует отдельный IPv4-адрес на каждого клиента. Stateful — экономит IPv4-адреса, но требует отслеживания состояния (как обычный NAT44 с трансляцией портов).

Дополнительные механизмы для NAT64

• SIIT (Stateless IP/ICMP Translation Algorithm, RFC 6145) — трансляция ICMP-сообщений между IPv4 и IPv6
• ALG (Application Layer Gateway) — расковыривание протоколов прикладного уровня (FTP, SIP и др.), которые передают IP-адреса внутри данных

Передача IPv4 через IPv6-сеть провайдера

Современный сценарий: провайдер имеет чистую IPv6-сеть, но клиенты хотят доступ к IPv4-интернету. На P-роутерах (внутри сети) IPv4 нет вообще, но на пограничных устройствах (PE) есть выход в оба интернета.

Carrier Grade NAT (CGNAT)

Провайдер выдает клиентам частные IPv4-адреса (из 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 или специального провайдерского блока 100.64.0.0/10) и выполняет трансляцию на границе сети с помощью CGNAT (Carrier Grade NAT) / LSN (Large Scale NAT).

DS-Lite (Dual-Stack Lite)

DS-Lite — Dual Stack без Dual Stack. Очень популярная технология.

Архитектура

[Клиент IPv4] → [B4 (CPE)] ══ IPv6-сеть провайдера ══ [AFTR] → [IPv4-интернет]

• B4 (Basic Bridging BroadBand) — CPE-устройство клиента
• AFTR (Address Family Transition Router) — провайдерский роутер с NAT

Принцип работы

1. CPE (B4) получает IPv4-пакет от клиента
2. Оборачивает его в 4in6 (без NAT на CPE!) и отправляет на IPv6-адрес AFTR
3. AFTR раскрывает содержимое, выполняет Large Scale NAT и отправляет IPv4-пакет в интернет
4. Обратные пакеты: AFTR по таблице трансляции восстанавливает IPv6-заголовок и отправляет на B4

Преимущества

Механизм DS-Lite очень популярен именно своей простотой.

• CPE дешевые, логики на них минимум — просто заворачивают IPv4 в IPv6
• Частные IPv4-адреса клиентов могут совпадать — AFTR различает клиентов по IPv6-адресам B4
• CPE могут быть преднастроены провайдером и раздавать Wi-Fi
• Нативные IPv6-пакеты от клиентов просто маршрутизируются напрямую

464XLAT

464XLAT (RFC 6877) — двойная трансляция: IPv4 → IPv6 → IPv4. Никакой инкапсуляции не используется.

Архитектура

[Клиент IPv4] → [CLAT] ── IPv6-сеть провайдера ── [PLAT] → [IPv4-интернет]

• CLAT (Customer-side Translator) — CPE или мобильное устройство
• PLAT (Provider-side Translator) — провайдерский роутер

Принцип работы

1. CLAT получает IPv4-пакет, выполняет Stateless NAT46 — перебивает заголовок на IPv6
2. В IPv6-адресе кодируются: идентификатор CLAT, оригинальный IPv4 получателя
3. По IPv6-сети пакет доходит до PLAT
4. PLAT выполняет Stateful NAT64 — перебивает обратно в IPv4, выполняет LSN

Применение в мобильных сетях

464XLAT широко используется в сетях 3GPP (LTE/4G). В 4G нельзя отправлять IPv4-пакеты напрямую — только IPv6. Мобильный телефон выступает в роли CLAT: при тезеринге (раздаче Wi-Fi) клиентские IPv4-пакеты транслируются прямо на устройстве.

MAP (Mapping of Address and Port)

MAP — технология, при которой NAT44 выполняется на клиентской CPE, а не на провайдерском роутере. Это снимает нагрузку с провайдерского оборудования.

MAP-T (Translation)

CPE выполняет NAT44 (получает публичный IPv4), затем Stateless NAT64 перебивает заголовок на IPv6. На Border Relay (BR) выполняется обратная Stateless-трансляция в IPv4.

[Клиент] → [CE: NAT44 + Stateless NAT64] ── IPv6 ── [BR: Stateless NAT64] → IPv4

MAP-E (Encapsulation)

CPE выполняет NAT44, затем оборачивает IPv4-пакет в IPv6-заголовок (4in6). На BR пакет просто раскрывается.

[Клиент] → [CE: NAT44 + 4in6] ══ IPv6 ══ [BR: декапсуляция] → IPv4

MAP-T vs MAP-E

Эти два стандарта долго конкурировали в рабочей группе IETF. Спор зашел в тупик — в итоге оба варианта стали стандартами в разных RFC.

Характеристика	MAP-T	MAP-E
Метод	Двойная трансляция	Инкапсуляция 4in6
CGNAT на провайдере	Не нужен	Не нужен
Инспекция трафика	Возможна	Затруднена (нужно расковыривать вложение)
Фрагментация	Проблемная	Нормальная

MAP выгоден провайдерам тем, что не нужен CGNAT — весь NAT44 выносится на клиентские устройства. Но если CPE дешевая и не справляется с большим трафиком (гигабит и выше), лучше использовать 464XLAT с мощным PLAT.

4RD

4RD — экспериментальное развитие MAP, сочетающее преимущества MAP-T и MAP-E:

• Использует инкапсуляцию 4in6 (как MAP-E)
• Позволяет инспектировать трафик
• Корректно транслирует ICMP
• Решает проблемы фрагментации MAP-T

Стандартизирован в конце 2015 года. Пока мало распространен в реальных сетях.

Итоги

Переходные технологии позволяют организовать связь между сегментами сети, если между ними нет полной связности для конкретной версии IP:

IPv6 поверх IPv4 (устаревшие):

• Статические туннели (6in4, GRE) — туннельные брокеры
• 6to4 — динамические туннели через anycast relay
• 6RD — контролируемый провайдером вариант 6to4
• Teredo — работает через NAT, но создает проблемы безопасности
• ISATAP, 6over4 — связь IPv6-сайтов через IPv4

IPv6 в IPv4 (трансляция):

• NAT-PT — устаревший, не рекомендуется
• NAT64 + DNS64 — современный стандарт

IPv4 через IPv6-сеть провайдера:

• DS-Lite — инкапсуляция 4in6, NAT на провайдере
• 464XLAT — двойная трансляция, популярен в мобильных сетях
• MAP-T / MAP-E — NAT на клиенте, без CGNAT
• 4RD — экспериментальное развитие MAP