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

IPv6 transition mechanism
Механизмы перехода IPv6
Стандарты Track
Экспериментальный
Информационная
Черновики
Не рекомендуется

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

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

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

IP без сохранения состояния /ICMP Перевод (СИИТ) переводит форматы заголовков пакетов в IPv6 и IPv4.[2] Метод SIIT определяет класс адресов IPv6, называемый IPv4-переведенный адреса.[3] У них есть приставка :: ffff: 0: 0: 0/96 и может быть записано как :: ffff: 0: a.b.c.d, в котором адрес в формате IPv4 a.b.c.d относится к С поддержкой IPv6 узел. Префикс был выбран для получения нулевого значения контрольная сумма чтобы избежать изменения контрольной суммы заголовка транспортного протокола.[4]Алгоритм может быть использован в решении, которое позволяет хостам IPv6, не имеющим постоянно назначенного адреса IPv4, связываться с хостами, поддерживающими только IPv4. Детали назначения адресов и маршрутизации в спецификации не рассматриваются. SIIT можно рассматривать как частный случай безгражданства. преобразование сетевых адресов.

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

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

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

6-й

Основная статья: Быстрое развертывание IPv6

6rd - это механизм, упрощающий быстрое развертывание службы IPv6 в IPv4 инфраструктуры интернет-провайдеров (Интернет-провайдеры). Он использует сопоставление адресов без сохранения состояния между 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
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, но находит только Записи, синтезирует записи AAAA из записей A. Первая часть синтезированного адреса IPv6 указывает на транслятор IPv6 / IPv4, а вторая часть включает IPv4-адрес из записи A. Рассматриваемый транслятор обычно представляет собой сервер NAT64. Стандартная спецификация DNS64 находится в RFC 6147.[11]

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

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

ISATAP

Основная статья: ISATAP

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

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

464XLAT

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

Клиент использует транслятор SIIT (см. Выше) для преобразования пакетов IPv4 (например, клиентского программного обеспечения Skype) в IPv6 для отправки (по сети, поддерживающей только IPv6) в NAT64 переводчик (см. выше), который переводит их обратно в IPv4 для отправки (по сети с поддержкой IPv4) на сервер, поддерживающий только IPv4 (например, сервер Skype). Переводчик SIIT (CLAT: cустомерский трансширотаили) может быть реализован на самом клиенте (как специальное программное обеспечение) или в промежуточной локальной сети с поддержкой IPv4 (но если бы у нее было подключение к Интернету по IPv4, 464XLAT не понадобился бы), и транслятор NAT64 (PLAT: птрансширотаили) должен иметь доступ как к серверу, так и к клиенту (через CLAT). Использование NAT64 ограничивает подключения к модели клиент-сервер с использованием UDP, TCP и ICMP.

Реализации

Dual-Stack Lite (DS-Lite)

«DS-Lite» перенаправляется сюда. Для системы видеоигр 2006 года см. Nintendo DS Lite.
DS-Lite

Двойной стек 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 позволяет интернет-провайдеру уменьшить количество отслеживаемых состояний для каждого подписчика, что улучшает масштабируемость инфраструктуры трансляции.

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

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

4-й

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

КАРТА

Отображение адреса и порта (MAP) - это Cisco IPv6 переход предложение, которое объединяет А + П трансляция адресов портов с туннелированием пакетов 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.

Реализации

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

Рекомендации

  • IPv6 на практике, Бенедикт Штокебранд (2006), ISBN 3-540-24524-3
  • RFC 2767, Удар в стеке
  • RFC 3338, Bump-in-the-API
  • RFC 3089, Шлюз на основе Socks
  • RFC 6219, Китайская образовательная и исследовательская сеть (CERNET) IVI Дизайн и развертывание перевода IVI для сосуществования и перехода IPv4 / IPv6
  1. ^ RFC 1726 - Технические критерии IPng
  2. ^ Ф. Бейкер; X. Li; К. Бао; К. Инь (апрель 2011 г.). Платформа для трансляции IPv4 / IPv6. IETF. Дои:10.17487 / RFC6144. RFC 6144.
  3. ^ К. Бао; C. Huitema; М. Багнуло; М. Букадар; X. Ли (октябрь 2010 г.). IPv6-адресация трансляторов IPv4 / IPv6. IETF. Дои:10.17487 / RFC6052. RFC 6052.
  4. ^ а б К. Бао; X. Li; Ф. Бейкер; Т. Андерсон; Ф. Гонт (июнь 2016 г.). Алгоритм трансляции IP / ICMP без сохранения состояния. Дои:10.17487 / RFC7915. RFC 7915.
  5. ^ Э. Нордмарк (февраль 2000 г.). Алгоритм трансляции IP / ICMP без сохранения состояния (SIIT). Сетевая рабочая группа. Дои:10.17487 / RFC2765. RFC 2765.
  6. ^ X. Li; К. Бао; Ф. Бейкер (Апрель 2011 г.). Алгоритм трансляции IP / ICMP. IETF. Дои:10.17487 / RFC6145. RFC 6145.
  7. ^ RFC: 3053
  8. ^ RFC 5569 Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd)
  9. ^ RFC 5969 Быстрое развертывание IPv6 в инфраструктурах IPv4 (6rd) - Спецификация протокола
  10. ^ RFC 6146 NAT64 с отслеживанием состояния: сетевой адрес и преобразование протокола от клиентов IPv6 к серверам IPv4
  11. ^ RFC 6147 DNS64: расширения DNS для преобразования сетевых адресов с клиентов IPv6 на серверы IPv4
  12. ^ «Видео: Live Demo 464XLAT на Всемирном конгрессе IPv6 в Париже». Интернет-общество. 3 апреля 2013 г.
  13. ^ «464XLAT - Решение для предоставления услуг IPv4 по сети и только IPv6». T-Mobile США. Получено 5 августа 2013.
  14. ^ «T-Mobile IPv6 здесь и сейчас». T-Mobile США. Получено 5 августа 2013.
  15. ^ Orange Polska # Мобильная сеть
  16. ^ «Разработка оборудования для Windows Phone».
  17. ^ «Основные возможности сетевого стека в Creators Update для Windows 10». Получено 26 июля 2017.
  18. ^ "Обновление Win10 CLAT". Получено 9 августа 2017.
  19. ^ "[v6ops] iOS12 только IPv6". Получено 5 ноября 2018.
  20. ^ ван Бейджнум, Ильич (16.06.2015). «Разработчики Apple и iOS: скоро появится сотовая служба, поддерживающая только IPv6, подготовьте свои приложения». Ars Technica. Получено 2 июля 2016.
  21. ^ "Обновление D19561 NAT64". Фабрикатор FreeBSD.
  22. ^ RFC 6333 - Широкополосное развертывание Dual-Stack Lite после исчерпания IPv4
  23. ^ Cui, Y .; Sun, Q .; Tsou, T .; Lee, Y .; Фаррер, И. (июль 2015 г.). Легкий 4over6: расширение архитектуры Dual-Stack Lite. IETF. Дои:10.17487 / RFC7596. RFC 7596. Получено 2018-05-25.
  24. ^ Марк Таунсли (24 сентября 2012 г.). «Сопоставление адреса + порта» (PDF). Cisco. Получено 2012-09-25.
  25. ^ Цунсяо, Бао; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. «Сопоставление адреса и порта с помощью трансляции (MAP-T)». tools.ietf.org. Получено 2018-06-07.
  26. ^ Цунсяо, Бао; Том, Тейлор; Войцех, декабрь; Син, Ли; Оле, Троан; Сатору, Мацусима; Тэцуя, Мураками. «Отображение адреса и порта с инкапсуляцией (MAP-E)». tools.ietf.org. Получено 2018-06-07.

внешняя ссылка