Механизм перехода IPv6

Механизмы перехода IPv6
Стандарты Track
4в6 Легкий 4over6 6 в 4 6over4 DS-Lite 6-й 6to4 NAT64 / DNS64 Тередо СИИТ КАРТА
Экспериментальный
TSP 4-й
Информационная
Туннельный брокер IVI TRT 464XLAT Общественные 4over6 ISATAP
Черновики
АЙЯ ДИВИ
Устарело
NAT-PT НАПТ-ПТ
v т е

Механизм перехода IPv6 представляет собой технологию , которая облегчает переходящую в Интернете от версии Internet Protocol 4 (IPv4) инфраструктур в эксплуатации с 1983 преемником адресацией и системы маршрутизации в Internet Protocol Version 6 (IPv6). Поскольку сети IPv4 и IPv6 не могут напрямую взаимодействовать друг с другом, технологии перехода предназначены для того, чтобы хосты любого типа сети могли взаимодействовать с любым другим хостом.

Чтобы соответствовать своим техническим критериям, IPv6 должен иметь простой план перехода с текущего IPv4. ^[1] Internet Engineering Task Force (IETF) проводит рабочие группы и дискуссии через IETF в Интернет Черновики и запрос на комментарии процессов разработки этих переходных технологий для достижения этой цели. Некоторые базовые механизмы перехода IPv6 определены в RFC 4213.

Трансляция IP / ICMP без сохранения состояния

Безгражданства IP / ICMP Перевод ( SIIT ) осуществляет преобразование между форматами заголовка пакета в IPv6 и IPv4 . ^[2] Метод SIIT определяет класс адресов IPv6, называемых адресами, преобразованными в IPv4 . ^[3] Они имеют префикс :: FFFF: 0: 0: 0 / 96 , и может быть записана в виде :: FFFF: 0: ABCD , в котором IPv4 - адрес , отформатированный ABCD относится к IPv6 с поддержкой узла. Префикс был выбран для получения контрольной суммы с нулевым значением, чтобы избежать изменений контрольной суммы заголовка транспортного протокола. ^[4]Алгоритм может использоваться в решении, которое позволяет хостам IPv6, не имеющим постоянно назначенного адреса IPv4, связываться с хостами, поддерживающими только IPv4. Детали назначения адресов и маршрутизации в спецификации не рассматриваются. SIIT можно рассматривать как частный случай трансляции сетевых адресов без сохранения состояния .

Спецификация является продуктом рабочей группы NGTRANS IETF и первоначально была разработана в феврале 2000 г. Э. Нордмарком из Sun Microsystems . ^[5] Он был пересмотрен в 2011 г. ^[6], а в 2016 г. был опубликован его текущий пересмотр. ^[4]

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

Туннельный брокер обеспечивает подключение по протоколу IPv6 путем инкапсуляции трафика IPv6 в транзитных Интернет ссылки IPv4, как правило , с использованием 6in4 . Это устанавливает туннели IPv6 в Интернете IPv4. Туннелями можно управлять с помощью протокола настройки туннеля (TSP) или AYIYA . ^[7]

6-й

6rd - это механизм, способствующий быстрому развертыванию службы IPv6 в инфраструктурах IPv4 поставщиков Интернет-услуг ( ISP ). Он использует сопоставление адресов без сохранения состояния между адресами IPv4 и IPv6 и передает пакеты IPv6 через автоматические туннели, которые следуют тем же оптимизированным маршрутам между узлами клиентов, что и пакеты IPv4 .

Он использовался для раннего крупного развертывания службы IPv6 с собственными адресами в 2007 году (RFC 5569 ^[8] ). Стандартная спецификация протокола находится в RFC 5969. ^[9]

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

RFC 3142 определяет метод трансляции транспортной ретрансляции ( TRT ). TRT использует преобразование DNS между записями AAAA и A, известное как DNS-ALG, как определено в RFC 2694.

NAT64

NAT64 и DNS64.

NAT64 - это механизм, позволяющий хостам IPv6 взаимодействовать с серверами IPv4. Сервер NAT64 является конечной точкой по крайней мере для одного IPv4-адреса и 32-битного сетевого сегмента IPv6, например, 64: ff9b :: / 96 (RFC 6052, RFC 6146). Клиент IPv6 встраивает адрес IPv4, с которым он хочет общаться, используя эти биты, и отправляет свои пакеты на полученный адрес. Затем сервер NAT64 создает NAT- сопоставление между IPv6 и IPv4-адресом, позволяя им обмениваться данными. ^[10]

DNS64

DNS64 описывает DNS-сервер, который при запросе записей AAAA домена , но находит только записи A , синтезирует записи AAAA из записей A. Первая часть синтезированного IPv6-адреса указывает на транслятор IPv6 / IPv4, а вторая часть включает IPv4-адрес из A-записи. Рассматриваемый транслятор обычно представляет собой сервер NAT64. Стандартная спецификация DNS64 находится в RFC 6147. ^[11]

У этого механизма перехода есть две заметные проблемы:

Это работает только в тех случаях, когда DNS используется для поиска адреса удаленного хоста, если используются литералы IPv4, сервер DNS64 никогда не будет задействован.
Поскольку серверу DNS64 необходимо возвращать записи, не указанные владельцем домена, проверка DNSSEC относительно корня не удастся в тех случаях, когда DNS-сервер, выполняющий перевод, не является сервером владельца домена.

ISATAP

ISATAP (протокол автоматической внутрисайтовой адресации туннелей) - это механизм перехода IPv6, предназначенный для передачи пакетов IPv6 между узлами с двойным стеком поверх сети IPv4.

В отличие от 6over4 (более старый аналогичный протокол, использующий многоадресную рассылку IPv4), ISATAP использует IPv4 в качестве уровня канала передачи данных виртуальной нешироковещательной сети с множественным доступом (NBMA), поэтому для поддержки многоадресной рассылки не требуется базовая сетевая инфраструктура IPv4.

464XLAT

464XLAT (RFC 6877) позволяет клиентам в сетях, поддерживающих только IPv6, получать доступ к Интернет-службам, поддерживающим только IPv4, таким как Skype. ^[12]^[13]

Клиент использует транслятор SIIT для преобразования пакетов из IPv4 в IPv6. Затем они отправляются транслятору NAT64, который переводит их из IPv6 обратно в IPv4 и далее на сервер, поддерживающий только IPv4. Клиентский транслятор может быть реализован на самом клиенте или на промежуточном устройстве и известен как CLAT (Customer-side transLATor). Транслятор NAT64 или PLAT (транслятор на стороне провайдера) должен иметь доступ как к серверу, так и к клиенту (через CLAT). Использование NAT64 ограничивает подключения к модели клиент-сервер с использованием UDP, TCP и ICMP.

Реализации

Есть реализация CLAT для Android, Android CLAT . T-Mobile USA обеспечивает NAT64 с услугой T-Mobile только для IPv6. ^[14]^{[ ненадежный источник? ]}
Orange Poland запустил службу только для IPv6 (CLAT / NAT64 / DNS) в сентябре 2013 года. ^[15]
Собственная реализация CLAT для Android появилась в Jelly Bean 4.3.
Windows Phone представила собственную реализацию CLAT в 2014 году с WP 8.1. ^[16]
Windows 10 (обновление Creators) имеет встроенную реализацию 464XLAT для настольных и мобильных устройств. Он включен для интерфейсов WWAN, когда оператор мобильной связи включил 464xlat в сети ^[17]^[18]
iOS 12.0 имеет встроенную реализацию CLAT. ^[19] Кроме того, Apple требует, чтобы все приложения, представленные в App Store, работали в сетях IPv6. ^[20]
clatd - это реализация CLAT для Linux .
Во FreeBSD были реализации CLAT начиная с 11.3 и 12.1. ^[21]

Двойной стек Lite (DS-Lite)

DS-Lite

Технология Dual-Stack Lite не предполагает присвоения IPv4-адреса оборудованию в помещении клиента (CPE) для обеспечения доступа в Интернет. Это описано в RFC 6333. CPE распределяет частные IPv4-адреса для клиентов LAN в соответствии с требованиями к сети в локальной сети. CPE инкапсулирует пакеты IPv4 в пакеты IPv6. CPE использует свое глобальное IPv6-соединение для доставки пакета в NAT операторского уровня провайдера.(CGN), имеющий глобальный IPv4-адрес. Исходный пакет IPv4 восстанавливается, и NAT выполняется для пакета IPv4 и направляется в общедоступный Интернет IPv4. CGN однозначно идентифицирует потоки трафика, записывая общедоступный IPv6-адрес CPE, частный IPv4-адрес и номер порта TCP или UDP в качестве сеанса. ^[22]

Облегченный 4over6 (RFC 7596) расширяет DS-Lite, перемещая функции NAT со стороны ISP на CPE, устраняя необходимость во внедрении NAT операторского уровня. ^[23] Это достигается путем выделения диапазона портов для общего адреса IPv4 каждому CPE. Перенос функции NAT на CPE позволяет интернет-провайдеру уменьшить количество отслеживаемых состояний для каждого подписчика, что улучшает масштабируемость инфраструктуры трансляции.

Проекты предложений

Эти механизмы все еще обсуждаются или от них отказались.

4-й

Остаточное развертывание IPv4 (4rd) - это механизм, указанный в RFC 7600, для облегчения остаточного развертывания службы IPv4 в сетях IPv6 . Как и 6rd , он использует сопоставление адресов без сохранения состояния между IPv6 и IPv4 . Он поддерживает расширение адресации IPv4 на основе портов транспортного уровня. Это вариант модели A + P без гражданства .

КАРТА

Сопоставление адреса и порта (MAP) - это предложение по переходу на Cisco IPv6, которое объединяет преобразование адресов порта A + P с туннелированием пакетов IPv4 по внутренней сети IPv6 провайдера . ^[24] По состоянию на июль 2015 ^{[Обновить]}г. MAP-T и MAP-E являются предлагаемыми стандартами. ^[25]^[26]

Устаревшие механизмы

Эти механизмы объявлены устаревшими IETF.

NAT-PT

Преобразование сетевых адресов / преобразование протоколов ( NAT-PT ) определено в RFC 2766, но из-за множества проблем оно было отменено в RFC 4966 и устарело до исторического статуса. Это , как правило , используется в сочетании с DNS - шлюза прикладного уровня (DNS-ALG) реализации.

НАПТ-ПТ

Будучи почти идентичным NAT-PT, преобразование сетевых адресов и портов + преобразование протоколов , которое также описано в RFC 2766, добавляет преобразование портов, а также адреса. Это делается в первую очередь для того, чтобы два хоста на одной стороне механизма не использовали один и тот же открытый порт на другой стороне механизма, что может вызвать нестабильность приложения и / или недостатки безопасности. Этот механизм объявлен устаревшим в RFC 4966.

Реализации

Stone (программное обеспечение) , переводчик портов для систем на базе Windows и Unix.
Верный , статическая реализация TRT на основе BSD проектом KAME
CLATD , реализация пограничного реле CLAT / SIIT-DC для Linux
WrapSix , реализация NAT64 для Linux
TAYGA , реализация NAT64 без сохранения состояния для Linux
Jool , реализация NAT64 с отслеживанием состояния для Linux
naptd , NAT-PT на уровне пользователя
Ecdysis , шлюз NAT64, включает DNS64
Маршрутизатор перехода к семейству адресов (AFTR) , реализация DS-Lite
niit Linux Kernel устройство, которое позволяет передавать одноадресный трафик IPv4 через сеть IPv6
Реализация трансляции пакетов IVI IPv4 / IPv6 в виде патча ядра Linux (только 2.6)
Microsoft Forefront Unified Access Gateway , решение обратного прокси и VPN, реализующее DNS64 и NAT64
BIND , DNS-сервер Berkeley Internet Name Domain, реализует DNS64, начиная с версии 9.8.
PF (брандмауэр) , фильтр пакетов OpenBSD поддерживает преобразование IP-версии, начиная с версии 5.1, включает NAT64

Смотрите также

Сравнение поддержки IPv6 в операционных системах
Softwire (протокол)

использованная литература

IPv6 на практике , Бенедикт Стокебранд (2006 г.), ISBN 3-540-24524-3
RFC 2767 , Bump-in-the-Stack
RFC 3338 , Bump-in-the-API
RFC 3089 , шлюз на базе Socks
RFC 6219 , Китайская образовательная и исследовательская сеть (CERNET) IVI Translation Design and Deployment for the IPv4 / IPv6 Coexistence and Transition

^ Куропатка, C .; Кастенхольц, Ф. (декабрь 1994 г.). Технические критерии выбора IP The Next Generation (IPng) . DOI : 10,17487 / RFC1726 . RFC 1726 .
^ Ф. Бейкер ; X. Li; К. Бао; К. Инь (апрель 2011 г.). Платформа для трансляции IPv4 / IPv6 . IETF . DOI : 10,17487 / RFC6144 . RFC 6144 .
^ К. Бао; C. Huitema; М. Багнуло; М. Букадар; X. Ли (октябрь 2010 г.). IPv6-адресация трансляторов IPv4 / IPv6 . IETF . DOI : 10,17487 / RFC6052 . RFC 6052 .
^ а б К. Бао; X. Li; Ф. Бейкер ; Т. Андерсон; Ф. Гонт (июнь 2016 г.). Алгоритм трансляции IP / ICMP без сохранения состояния . DOI : 10,17487 / RFC7915 . RFC 7915 .
↑ Э. Нордмарк (февраль 2000 г.). Алгоритм трансляции IP / ICMP без сохранения состояния (SIIT) . Сетевая рабочая группа. DOI : 10,17487 / RFC2765 . RFC 2765 .
^ X. Li; К. Бао; Ф. Бейкер (апрель 2011 г.). Алгоритм трансляции IP / ICMP . IETF . DOI : 10,17487 / RFC6145 . RFC 6145 .
^ RFC: 3053
Перейти ↑ Despres, R. (январь 2010). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd) . DOI : 10,17487 / RFC5569 . RFC 5569 .
^ Troan, О. (август 2010). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd) - Спецификация протокола . DOI : 10,17487 / RFC5969 . RFC 5969 .
^ Bagnulo, M .; Matthews, P .; ван Бейджнум, И. (апрель 2011 г.). NAT64 с отслеживанием состояния: сетевой адрес и преобразование протокола от клиентов IPv6 к серверам IPv4 . DOI : 10,17487 / RFC6146 . RFC 6146 .
^ Bagnulo, M .; Салливан, А .; Matthews, P .; ван Бейджнум, И. (апрель 2011 г.). DNS64: расширения DNS для преобразования сетевых адресов с клиентов IPv6 на серверы IPv4 . DOI : 10,17487 / RFC6147 . RFC 6147 .
^ "Видео: 464XLAT Live Demo на Всемирном конгрессе IPv6 в Париже" . Интернет-сообщество . 3 апреля 2013 г.
^ «464XLAT - Решение для предоставления услуг IPv4 по сети и только IPv6» . T-Mobile USA . Проверено 5 августа 2013 года .
^ «T-Mobile IPv6 здесь и сейчас» . T-Mobile USA . Проверено 5 августа 2013 года .
^ Orange Polska # Мобильная сеть
^ «Разработка оборудования Windows Phone» .
^ «Основные возможности сетевого стека в Creators Update для Windows 10» . Проверено 26 июля 2017 года .
^ "Win10 update CLAT" . Дата обращения 9 августа 2017 .
^ "[v6ops] iOS12 только для IPv6" . Проверено 5 ноября 2018 .
^ ван Бейджнум, Ильич (2015-06-16). «Разработчики от Apple до iOS: скоро появится сотовая служба, поддерживающая только IPv6, подготовьте свои приложения» . Ars Technica . Проверено 2 июля +2016 .
^ "Обновление D19561 NAT64" . Фабрикатор FreeBSD .
^ Durand, A .; Droms, R .; Woodyatt, J .; Ли, Ю. (август 2011 г.). Широкополосное развертывание Dual-Stack Lite после исчерпания IPv4 . DOI : 10,17487 / RFC6333 . RFC 6333 .
^ Cui, Y .; Sun, Q .; Tsou, T .; Lee, Y .; Фаррер, И. (июль 2015 г.). Легкий 4over6: расширение архитектуры Dual-Stack Lite . IETF . DOI : 10,17487 / RFC7596 . RFC 7596 . Проверено 25 мая 2018 .
^ Марк Townsley (24 сентября 2012). «Отображение адреса + порта» (PDF) . Cisco . Проверено 25 сентября 2012 .
^ Цунсяо, Бао; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. Сопоставление адреса и порта с помощью трансляции (MAP-T) . DOI : 10,17487 / RFC7599 . RFC 7599 . Проверено 7 июня 2018 .
^ Цунсяо, Бао; Том, Тейлор; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. Отображение адреса и порта с инкапсуляцией (MAP-E) . DOI : 10,17487 / RFC7597 . RFC 7597 . Проверено 7 июня 2018 .

внешние ссылки

DJ Bernstein - Беспорядок с IPv6
TRT Howto с 2013 года
IPv6 - перспективы и проблемы: техническое и управленческое исследование развертывания IPv6
Сетевой мир: понимание Dual-Stack Lite
Проект IETF: структура для трансляции IPv4 / IPv6
Переход и сосуществование IPv4 и IPv6 , проект 6DEPLOY, 2011 г.
Обеспечение взаимодействия между гетерогенными (сети IPv4 / IPv6 без использования трансляции протоколов , Технический обзор IETE, 2012 г.)
Настройка хостов для автоматического определения (IPv6, IPv6-in-IPv4 или IPv4) сетевого подключения , KSII-ТРАНЗАКЦИИ В ИНТЕРНЕТЕ И ИНФОРМАЦИОННЫХ СИСТЕМАХ, 2011 г.
IPv6: NAT-PT против NAT64 Джанрико Фишера, 2012 г.

[RFC1726-1] Куропатка, C .; Кастенхольц, Ф. (декабрь 1994 г.). Технические критерии выбора IP The Next Generation (IPng) . DOI : 10,17487 / RFC1726 . RFC 1726 .

[rfc6144-2] Ф. Бейкер ; X. Li; К. Бао; К. Инь (апрель 2011 г.). Платформа для трансляции IPv4 / IPv6 . IETF . DOI : 10,17487 / RFC6144 . RFC 6144 .

[rfc6052-3] К. Бао; C. Huitema; М. Багнуло; М. Букадар; X. Ли (октябрь 2010 г.). IPv6-адресация трансляторов IPv4 / IPv6 . IETF . DOI : 10,17487 / RFC6052 . RFC 6052 .

[rfc7915-4] а б К. Бао; X. Li; Ф. Бейкер ; Т. Андерсон; Ф. Гонт (июнь 2016 г.). Алгоритм трансляции IP / ICMP без сохранения состояния . DOI : 10,17487 / RFC7915 . RFC 7915 .

[rfc2765-5] Э. Нордмарк (февраль 2000 г.). Алгоритм трансляции IP / ICMP без сохранения состояния (SIIT) . Сетевая рабочая группа. DOI : 10,17487 / RFC2765 . RFC 2765 .

[RFC6145-6] X. Li; К. Бао; Ф. Бейкер (апрель 2011 г.). Алгоритм трансляции IP / ICMP . IETF . DOI : 10,17487 / RFC6145 . RFC 6145 .

[first-7] RFC: 3053

[RFC5569-8] Перейти ↑ Despres, R. (январь 2010). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd) . DOI : 10,17487 / RFC5569 . RFC 5569 .

[RFC5969-9] Troan, О. (август 2010). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd) - Спецификация протокола . DOI : 10,17487 / RFC5969 . RFC 5969 .

[RFC6146-10] Bagnulo, M .; Matthews, P .; ван Бейджнум, И. (апрель 2011 г.). NAT64 с отслеживанием состояния: сетевой адрес и преобразование протокола от клиентов IPv6 к серверам IPv4 . DOI : 10,17487 / RFC6146 . RFC 6146 .

[RFC6147-11] Bagnulo, M .; Салливан, А .; Matthews, P .; ван Бейджнум, И. (апрель 2011 г.). DNS64: расширения DNS для преобразования сетевых адресов с клиентов IPv6 на серверы IPv4 . DOI : 10,17487 / RFC6147 . RFC 6147 .

[12] "Видео: 464XLAT Live Demo на Всемирном конгрессе IPv6 в Париже" . Интернет-сообщество . 3 апреля 2013 г.

[13] «464XLAT - Решение для предоставления услуг IPv4 по сети и только IPv6» . T-Mobile USA . Проверено 5 августа 2013 года .

[14] «T-Mobile IPv6 здесь и сейчас» . T-Mobile USA . Проверено 5 августа 2013 года .

[15] Orange Polska # Мобильная сеть

[16] «Разработка оборудования Windows Phone» .

[17] «Основные возможности сетевого стека в Creators Update для Windows 10» . Проверено 26 июля 2017 года .

[18] "Win10 update CLAT" . Дата обращения 9 августа 2017 .

[19] "[v6ops] iOS12 только для IPv6" . Проверено 5 ноября 2018 .

[20] ван Бейджнум, Ильич (2015-06-16). «Разработчики от Apple до iOS: скоро появится сотовая служба, поддерживающая только IPv6, подготовьте свои приложения» . Ars Technica . Проверено 2 июля +2016 .

[21] "Обновление D19561 NAT64" . Фабрикатор FreeBSD .

[22] Durand, A .; Droms, R .; Woodyatt, J .; Ли, Ю. (август 2011 г.). Широкополосное развертывание Dual-Stack Lite после исчерпания IPv4 . DOI : 10,17487 / RFC6333 . RFC 6333 .

[23] Cui, Y .; Sun, Q .; Tsou, T .; Lee, Y .; Фаррер, И. (июль 2015 г.). Легкий 4over6: расширение архитектуры Dual-Stack Lite . IETF . DOI : 10,17487 / RFC7596 . RFC 7596 . Проверено 25 мая 2018 .

[24] Марк Townsley (24 сентября 2012). «Отображение адреса + порта» (PDF) . Cisco . Проверено 25 сентября 2012 .

[25] Цунсяо, Бао; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. Сопоставление адреса и порта с помощью трансляции (MAP-T) . DOI : 10,17487 / RFC7599 . RFC 7599 . Проверено 7 июня 2018 .

[26] Цунсяо, Бао; Том, Тейлор; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. Отображение адреса и порта с инкапсуляцией (MAP-E) . DOI : 10,17487 / RFC7597 . RFC 7597 . Проверено 7 июня 2018 .

[1]