Механизм перехода 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 - это механизм, позволяющий хостам 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)
Технология 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
- ^ RFC 1726 - Технические критерии IPng
- ^ Ф. Бейкер ; 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
- ^ RFC 5569 Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd)
- ^ RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructure (6rd) - Спецификация протокола
- ^ RFC 6146 Stateful NAT64: сетевой адрес и преобразование протокола от клиентов IPv6 к серверам IPv4
- ^ RFC 6147 DNS64: расширения DNS для трансляции сетевых адресов с клиентов IPv6 на серверы IPv4
- ^ «Видео: 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 CLAT" . Дата обращения 9 августа 2017 .
- ^ "[v6ops] iOS12 только IPv6" . Проверено 5 ноября 2018 .
- ^ ван Бейджнум, Ильич (16.06.2015). «Разработчики Apple для iOS: скоро появится сотовая служба, поддерживающая только IPv6, подготовьте свои приложения» . Ars Technica . Дата обращения 2 июля 2016 .
- ^ «Обновление D19561 NAT64» . Фабрикатор FreeBSD .
- ^ RFC 6333 - Широкополосное развертывание Dual-Stack Lite после исчерпания IPv4
- ^ Cui, Y .; Sun, Q .; Tsou, T .; Lee, Y .; Фаррер, И. (июль 2015 г.). Легкий 4over6: расширение архитектуры Dual-Stack Lite . IETF . DOI : 10,17487 / RFC7596 . RFC 7596 . Проверено 25 мая 2018 .
- ^ Марк Таунсли (24 сентября 2012 г.). «Отображение адреса + порта» (PDF) . Cisco . Проверено 25 сентября 2012 .
- ^ Цунсяо, Бао; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. «Отображение адреса и порта с использованием трансляции (MAP-T)» . tools.ietf.org . Проверено 7 июня 2018 .
- ^ Цунсяо, Бао; Том, Тейлор; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. «Отображение адреса и порта с инкапсуляцией (MAP-E)» . tools.ietf.org . Проверено 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 г.