stringtranslate.com

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

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

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

Перевод IP/ICMP без сохранения состояния

Stateless IP/ ICMP Translation ( 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) [7] или AYIYA [8] .

6-й

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

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

Транспортное реле Перевод

RFC 3142 определяет метод Transport Relay Translation ( TRT ). TRT действует как промежуточное устройство между двумя хостами. Функция транслятора заключается в преобразовании адресов IPV6 в IPV4 и наоборот. TRT выполняет это преобразование посредством сопоставления IP-адресов и пользовательского IP-адреса. [11]

Адрес, например, если пакеты должны передаваться с адреса IPv6 (fec0:0:0:1::/64) на адрес IPV4 (10.1.1.1) будет выглядеть как fec0:0:0:1::10.1.1.1. Пакеты сначала направляются к транслятору через протокол IPv6/TCP, а затем от транслятора к хосту IPv4 через протокол IPv4/TCP. [12]

TRT использует операцию, похожую на DNS-трансляцию между записями AAAA и A, известную как DNS-ALG, как определено в RFC 2694. [13]

НАТ64

NAT64 и DNS64

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

DNS64

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

С этим механизмом перехода связаны две заметные проблемы:

# DNS-резолвер 2606:4700:4700:64 синтезирует записи AAAA для # ipv6test.google.com в адрес NAT64: 64:ff9b::<original-ipv4> $ nslookup ipv6test.google.com 2606:4700:4700::64Неавторитетный ответ : ipv6test.google.com каноническое имя = ipv6test.l.google.com. Имя : ipv6test.l.google.com Адрес : 64:ff9b::8efa:c3e4
Реализации

ИСАТАП

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

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

464XLAT

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

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

Реализации

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

DS-Lite

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

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

Маршрутизация V4-через-v6

Маршрутизация V4-via-v6 — это метод, при котором адреса IPv4 назначаются только конечным хостам, а промежуточным маршрутизаторам назначаются только адреса IPv6. Маршруты IPv4 распространяются как обычно, и не применяется трансляция или инкапсуляция пакетов, а используется следующий переход IPv6. V4-via-v6 сокращает объем требуемого управления, поскольку базовой сети необходимо назначить только адреса IPv6, но по-прежнему требует, чтобы базовая сеть могла пересылать пакеты IPv4.

V4-via-v6 определен для протокола пограничного шлюза (BGP) [33] и протокола маршрутизации Babel . [34] Он был реализован демоном маршрутизации Bird Internet [35] и в babeld . [36]

КАРТА

Сопоставление адреса и порта (MAP) — это предложение Cisco по переходу на IPv6 , которое объединяет преобразование адресов портов A+P с туннелированием пакетов IPv4 по внутренней сети IPv6 провайдера интернет-услуг . [37] MAP-T [38] и MAP-E [39] вошли в стандартную комплектацию в июле 2015 года, а Sky Italia развернула MAP-T в своих интернет-сервисах уже в 2021 году. [40]

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

Следующие механизмы все еще обсуждаются или были отклонены IETF:

4-й

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

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

Эти механизмы были признаны устаревшими IETF:

NAT-PT

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

NAPT-PT

Хотя практически идентичны NAT-PT, Network Address Port Translation + Protocol Translation , которые также описаны в RFC 2766, добавляют трансляцию портов, а также адреса. Это делается в первую очередь для того, чтобы избежать использования двумя хостами на одной стороне механизма одного и того же открытого порта на другой стороне механизма, что может привести к нестабильности приложения и уязвимостям безопасности. Этот механизм был устарел в RFC 4966.

Реализации

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

Ссылки

  1. ^ Партридж, К.; Кастенхольц, Ф. (декабрь 1994 г.). Технические критерии выбора IP следующего поколения (IPng). doi : 10.17487/RFC1726 . RFC 1726.
  2. ^ F. Baker ; X. Li; C. Bao; K. Yin (апрель 2011 г.). Framework for IPv4/IPv6 Translation. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6144 . ISSN  2070-1721. RFC 6144. Информационный.
  3. ^ ab C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (октябрь 2010 г.). Адресация IPv6 трансляторов IPv4/IPv6. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6052 . ISSN  2070-1721. RFC 6052. Предложенный стандарт. Обновления RFC 4291.
  4. ^ ab C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (июнь 2016 г.). Алгоритм трансляции IP/ICMP без сохранения состояния. doi : 10.17487/RFC7915 . RFC 7915.
  5. ^ E. Nordmark (февраль 2000 г.). Stateless IP/ICMP Translation Algorithm (SIIT). Сетевая рабочая группа. doi : 10.17487/RFC2765 . RFC 2765. Устарело. Устарело согласно RFC 6145.
  6. ^ X. Li; C. Bao; F. Baker (апрель 2011 г.). Алгоритм трансляции IP/ICMP. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6145 . ISSN  2070-1721. RFC 6145. Устарело. Устарело согласно RFC 7915. Обновлено согласно RFC 6791 и 7757.
  7. ^ М. Бланше; Ф. Пэрент (февраль 2010 г.). IPv6 Tunnel Broker с протоколом Tunnel Setup Protocol (TSP). doi : 10.17487/RFC5572 . ISSN  2070-1721. RFC 5572. Экспериментальный.
  8. ^ A. Durand; P. Fasano; I. Guardini; D. Lento (январь 2001 г.). IPv6 Tunnel Broker. Сетевая рабочая группа. doi : 10.17487/RFC3053 . RFC 3053. Информационный.
  9. ^ Депре, Р. (январь 2010 г.). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6-е). doi : 10.17487/RFC5569 . RFC 5569.
  10. ^ Троан, О. (август 2010 г.). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6-е) – Спецификация протокола. doi : 10.17487/RFC5969 . RFC 5969.
  11. ^ Хагино, Дж.; Ямамото, К. (июнь 2001 г.). «Транслятор транспортного ретранслятора IPv6-в-IPv4». rfc-editor.org . Запрос комментариев редактора . Получено 28 июня 2024 г. .
  12. ^ Шанмугараджа, П. «Проектирование и реализация транслятора транспортного реле и меры по снижению его безопасности». researchgate.net . Research Gate . Получено 28 июня 2024 г. .
  13. ^ Хеффернан, Энди; Цирцис, Джордж; Шрисуреш, Пайда; Аккираджу, Правин (сентябрь 1999 г.). «Расширения DNS для трансляторов сетевых адресов (DNS_ALG)». rfc-editor.org . Получено 28 июня 2024 г. .
  14. ^ M. Bagnulo; P. Matthews; I. van Beijnum (апрель 2011 г.). Stateful NAT64: трансляция сетевых адресов и протоколов от клиентов IPv6 к серверам IPv4. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6146 . ISSN  2070-1721. RFC 6146. Предлагаемый стандарт.
  15. ^ Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (апрель 2011 г.). DNS64: расширения DNS для трансляции сетевых адресов с клиентов IPv6 на серверы IPv4. doi : 10.17487/RFC6147 . RFC 6147.
  16. ^ "README.DNS64". GitHub . Архивировано из оригинала 2024-04-07 . Получено 2024-04-07 .
  17. ^ Žorž, Jan (3 апреля 2013 г.). "Видео: 464XLAT Live Demo на Всемирном конгрессе IPv6 в Париже". Internet Society . Архивировано из оригинала 13 сентября 2017 г. Получено 5 августа 2013 г.
  18. ^ "464XLAT – Решение для предоставления услуг IPv4 по сети IPv6-only". T-Mobile USA . Архивировано из оригинала 12 ноября 2020 года . Получено 5 августа 2013 года .
  19. ^ "Исследование случая: T-Mobile US переходит только на IPv6 с помощью 464XLAT". Internet Society . 13 июня 2014 г. Архивировано из оригинала 4 февраля 2024 г. Получено 15 января 2023 г.
  20. ^ Твардовска, Марта (6 января 2015 г.). «Orange Polska запустила первое в мире инновационное решение IPv6 с SoftAtHome». Business Wire . Архивировано из оригинала 2023-01-15 . Получено 2023-01-15 .
  21. ^ "Telstra IPv6 Wireless Enablement – ​​IPv6 Single Stack". 6 февраля 2020 г. Архивировано из оригинала 12 июня 2023 г. Получено 12 июня 2023 г.
  22. ^ Drown, Dan. «Что такое Android CLAT?». Заметки Дэна . Архивировано из оригинала 17 декабря 2022 г. Получено 15 января 2023 г.
  23. ^ Havey, Daniel; Balasubramanian, Praveen (14 февраля 2019 г.). «Основные функции сетевого стека в обновлении Creators Update для Windows 10». Блог Microsoft Networking . Архивировано из оригинала 1 февраля 2023 г. Получено 15 января 2023 г.
  24. ^ "Windows 11 Plans to Expand CLAT Support". Блог Microsoft Networking . Архивировано из оригинала 8 марта 2024 г. Получено 7 марта 2024 г.
  25. ^ "Twitter" . Получено 27 июня 2022 г.
  26. ^ "[v6ops] iOS12 IPv6-only" . Получено 5 ноября 2018 г. .
  27. ^ ван Бейнум, Ильич (16.06.2015). «Apple для разработчиков iOS: скоро появится сотовая служба только на базе IPv6, готовьте свои приложения». Ars Technica . Архивировано из оригинала 28.06.2016 . Получено 2 июля 2016 г.
  28. ↑ Андерсон, Торе (20 мая 2019 г.). "clatd". GitHub . Архивировано из оригинала 17 декабря 2022 г. . Получено 15 января 2023 г. .
  29. ^ "OpenWrt Wiki package: 464xlat". OpenWrt . Получено 1 апреля 2024 г. .
  30. ^ Baoi, Danilo G. (19 июня 2021 г.). "FreeBSD 12.1-RELEASE Release Notes". FreeBSD . Архивировано из оригинала 15 января 2023 г. . Получено 15 января 2023 г. .
  31. ^ A. Durand; R. Droms; J. Woodyatt; Y. Lee (август 2011 г.). Развертывание широкополосной связи Dual-Stack Lite после исчерпания IPv4. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6333 . ISSN  2070-1721. RFC 6333. Предлагаемый стандарт.
  32. ^ Y. Cui; Q. Sun; M. Boucadair; T. Tsou; Y. Lee; I. Farrer (июль 2015 г.). Облегченный 4over6: расширение архитектуры Dual-Stack Lite. Internet Engineering Task Force . doi : 10.17487/RFC7596 . ISSN  2070-1721. RFC 7596. Предлагаемый стандарт.
  33. ^ Ле Фошер, Франсуа; Розен, Эрик (май 2009 г.). Реклама информации о доступности сетевого уровня IPv4 с помощью следующего перехода IPv6. doi : 10.17487/RFC5549 . RFC 5549.
  34. ^ Chroboczek, Juliusz (май 2022 г.). Маршруты Pv4 с IPv6 Next Hop в протоколе маршрутизации Babel. doi : 10.17487/RFC9229 . RFC 9229.
  35. ^ Rammhold, Andreas (15 декабря 2020 г.). "[RFC] Babel: Добавить поддержку v4viav6". BIRD Internet Routing Daemon . Архивировано из оригинала 29.12.2022 . Получено 15.01.2023 .
  36. ^ Chroboczek, Juliusz (5 мая 2022 г.). "[Babel-users] ОБЪЯВЛЕНИЕ: babeld-1.12". Списки Debian Alioth . Архивировано из оригинала 29-12-2022 . Получено 15-01-2023 .
  37. ^ Марк Таунсли (24 сентября 2012 г.). "Mapping Address + Port" (PDF) . Cisco. Архивировано (PDF) из оригинала 2022-12-29 . Получено 2012-09-25 .
  38. ^ X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (июль 2015 г.). W. Dec (ред.). Сопоставление адреса и порта с использованием трансляции (MAP-T). Internet Engineering Task Force (IETF). doi : 10.17487/RFC7599 . ISSN  2070-1721. RFC 7599. Предлагаемый стандарт.
  39. ^ W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (июль 2015 г.). O. Troan; T. Taylor (ред.). Сопоставление адреса и порта с инкапсуляцией (MAP-E). Internet Engineering Task Force (IETF). doi : 10.17487/RFC7597 . ISSN  2070-1721. RFC 7597. Предлагаемый стандарт.
  40. ^ Паттерсон, Ричард (май 2021 г.). «IPv6-Only with MAP-T». RIPE NCC Open House . Архивировано из оригинала 21 февраля 2023 г. Получено 1 августа 2023 г.
  41. ^ R. Despres; R. Penno; Y. Lee; G. Chen; M. Chen (июль 2015 г.). S. Jiang (ред.). Остаточное развертывание IPv4 через IPv6 — решение без сохранения состояния (4-е). Internet Engineering Task Force (IETF). doi : 10.17487/RFC7600 . ISSN  2070-1721. RFC 7600. Экспериментальный.

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