✖


Jump to content

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

Механизмы перехода IPv6
Стандарты
Экспериментальный
Информационный
Черновики
Устарело

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

Чтобы соответствовать техническим критериям, IPv6 должен иметь простой план перехода от текущего IPv4. [ 1 ] Целевая группа по проектированию Интернета 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 , в котором адрес abcd в формате IPv4 относится к узлу с поддержкой IPv6 . Префикс был выбран для получения контрольной суммы с нулевым значением , чтобы избежать изменений в контрольной сумме заголовка транспортного протокола. [ 4 ] Алгоритм можно использовать в решении, которое позволяет узлам IPv6, не имеющим постоянно назначенного адреса IPv4, взаимодействовать с узлами, поддерживающими только IPv4. Назначение адресов и детали маршрутизации не рассматриваются в спецификации. SIIT можно рассматривать как частный случай трансляции сетевых адресов без сохранения состояния .

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

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

[ редактировать ]

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

6-й

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

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

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

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

[ редактировать ]

RFC 3142 определяет метод трансляции транспортной релейной передачи ( 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 ]

NAT64

[ редактировать ]
Основная статья: NAT64
НАТ64 и DNS64

NAT64 — это механизм, позволяющий хостам IPv6 взаимодействовать с серверами IPv4. Сервер NAT64 является конечной точкой как минимум для одного адреса IPv4 и 32-битного сегмента сети IPv6, например 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 используется для поиска адреса удаленного хоста. Если используются литералы IPv4, сервер DNS64 никогда не будет задействован.
  • Поскольку серверу DNS64 необходимо возвращать записи, не указанные владельцем домена, DNSSEC проверка на соответствие корню завершится неудачно в тех случаях, когда DNS-сервер, выполняющий преобразование, не является сервером владельца домена. 
# DNS resolver 2606:4700:4700:64 synthesizes AAAA records for
# ipv6test.google.com to a NAT64 address: 64:ff9b::<original-ipv4>
$ nslookup ipv6test.google.com 2606:4700:4700::64

Non-authoritative answer:
ipv6test.google.com	canonical name = ipv6test.l.google.com.
Name:	ipv6test.l.google.com
Address: 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 (TransLATor на стороне клиента). Транслятор NAT64, или PLAT (transLATor на стороне поставщика), должен иметь возможность связаться как с сервером, так и с клиентом (через CLAT). Использование NAT64 ограничивает соединения моделью клиент-сервер с использованием UDP, TCP и ICMP.

Реализации
  • T-Mobile US стала использовать только IPv6, используя 464XLAT. [ 19 ]
  • Orange Polska запустила услугу только IPv6 (CLAT/NAT64/DNS) в сентябре 2013 года, переведя все ADSL , VDSL и FTTH к январю 2015 года. шлюзы [ 20 ]
  • В феврале 2020 года Telstra стала использовать только IPv6 для мобильных сервисов, использующих 464XLAT. [ 21 ]
  • Android включает встроенную реализацию CLAT начиная с версии Jelly Bean 4.3, выпущенной в 2013 году. [ 22 ]
  • Windows 10 имеет встроенную реализацию 464XLAT только для WWAN для настольных компьютеров и мобильных устройств, начиная с обновления Creators Update 2017 года . [ 23 ]
  • Windows 11 (23H2) имеет ту же реализацию, что и Windows 10. В будущей версии поддержка CLAT будет расширена на другие сетевые устройства (в настоящее время ограничена WWAN). В реализации будут использоваться стандарты RFC 7050 (DNS-запрос ipv4only.arpa), RFC 8781 (PREF64 и RFC 8925 (DHCP Option 108). [ 24 ]
  • В macOS появится встроенная поддержка CLAT в Ventura, выпущенной в 2022 году. [ 25 ]
  • iOS имеет встроенную реализацию CLAT, начиная с версии 12.0, выпущенной в 2018 году. [ 26 ] Кроме того, Apple требует, чтобы все приложения, отправленные в App Store, работали в сетях IPv6. [ 27 ]
  • clatd — это реализация CLAT для Linux . [ 28 ]
  • ОС OpenWRT Linux для маршрутизаторов имеет дополнительную поддержку clat через пакет 464xlat. [ 29 ]

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

[ редактировать ]
«DS-Lite» перенаправляется сюда. Информацию о системе видеоигр 2006 года см. в Nintendo DS Lite .
ДС-Лайт

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

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

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

[ редактировать ]

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

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

КАРТА

[ редактировать ]

Сопоставление адреса и порта (MAP) — это Cisco по переходу на IPv6 предложение , которое сочетает в себе преобразование адресов портов A+P поставщика услуг Интернета с туннелированием пакетов IPv4 через внутреннюю сеть IPv6 . [ 37 ] МАП-Т [ 38 ] и МАП-Э [ 39 ] вступила на путь стандартов в июле 2015 года, а Sky Italia внедрила MAP-T в свои интернет-сервисы уже в 2021 году. [ 40 ]

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

[ редактировать ]

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

4-й

[ редактировать ]

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

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

[ редактировать ]

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

НОЧЬ-ПТ

[ редактировать ]

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

НАПТ-ПТ

[ редактировать ]

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

Реализации

[ редактировать ]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Партридж, К.; Кастенхольц, Ф. (декабрь 1994 г.). Технические критерии выбора IP следующего поколения (IPng) . дои : 10.17487/RFC1726 . РФК 1726 .
  2. ^ Ф. Бейкер ; С. Ли; К. Бао; К. Инь (апрель 2011 г.). Платформа для трансляции IPv4/IPv6 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6144 . ISSN   2070-1721 . RFC 6144 . Информационный.
  3. ^ Перейти обратно: а б К. Бао; К. Уитема ; М. Багнуло; М. Букадер; С. Ли (октябрь 2010 г.). IPv6-адресация трансляторов IPv4/IPv6 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6052 . ISSN   2070-1721 . РФК 6052 . Предлагаемый стандарт. Обновления РФК 4291 .
  4. ^ Перейти обратно: а б К. Бао; С. Ли; Ф. Бейкер ; Т. Андерсон; Ф. Гонт (июнь 2016 г.). Алгоритм трансляции IP/ICMP без сохранения состояния . дои : 10.17487/RFC7915 . РФК 7915 .
  5. ^ Э. Нордмарк (февраль 2000 г.). Алгоритм трансляции IP/ICMP без сохранения состояния (SIIT) . Сетевая рабочая группа. дои : 10.17487/RFC2765 . РФК 2765 . Устаревший. Устарело РФК 6145 .
  6. ^ С. Ли; К. Бао; Ф. Бейкер (апрель 2011 г.). Алгоритм трансляции IP/ICMP . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6145 . ISSN   2070-1721 . РФК 6145 . Устаревший. Устарело RFC 7915. Updated by RFC 6791 и 7757 .
  7. ^ М. Бланше; Ф. Пэрент (февраль 2010 г.). Туннельный брокер IPv6 с протоколом настройки туннеля (TSP) . дои : 10.17487/RFC5572 . ISSN   2070-1721 . RFC 5572 . Экспериментальный.
  8. ^ А. Дюран; П. Фазано; И. Гвардини; Д. Ленто (январь 2001 г.). Брокер туннелей IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC3053 . РФК 3053 . Информационный.
  9. ^ Депре, Р. (январь 2010 г.). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6-е место) . дои : 10.17487/RFC5569 . РФК 5569 .
  10. ^ Троан, О. (август 2010 г.). Быстрое развертывание IPv6 в инфраструктурах IPv4 (6-е место) – Спецификация протокола . дои : 10.17487/RFC5969 . РФК 5969 .
  11. ^ Хагино, Дж.; Ямамото, К. (июнь 2001 г.). «Переводчик транспортных реле с IPv6 на IPv4» . rfc-editor.org . Просьба к редактору комментариев . Проверено 28 июня 2024 г.
  12. ^ Шанмугараджа, П. «Проектирование и реализация транслятора транспортных реле и меры по снижению его безопасности» . www.researchgate.net . Исследовательские ворота . Проверено 28 июня 2024 г.
  13. ^ Хеффернан, Энди; Цирцис, Георгий; Шрисуреш, Пида; Аккираджу, Правин (сентябрь 1999 г.). «Расширения DNS для переводчиков сетевых адресов (DNS_ALG)» . rfc-editor.org . Проверено 28 июня 2024 г.
  14. ^ М. Багнуло; П. Мэтьюз; И. ван Бейнум (апрель 2011 г.). NAT64 с сохранением состояния: трансляция сетевых адресов и протоколов от клиентов IPv6 на серверы IPv4 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6146 . ISSN   2070-1721 . РФК 6146 . Предлагаемый стандарт.
  15. ^ Багнуло, М.; Салливан, А.; Мэтьюз, П.; ван Бейнум, И. (апрель 2011 г.). DNS64: расширения DNS для трансляции сетевых адресов с клиентов IPv6 на серверы IPv4 . дои : 10.17487/RFC6147 . RFC 6147 .
  16. ^ «README.DNS64» . Гитхаб . Архивировано из оригинала 7 апреля 2024 г. Проверено 7 апреля 2024 г.
  17. ^ Жорж, Ян (3 апреля 2013 г.). «Видео: живая демонстрация 464XLAT на Всемирном конгрессе IPv6 в Париже» . Интернет-сообщество . Архивировано из оригинала 13 сентября 2017 года . Проверено 5 августа 2013 г.
  18. ^ «464XLAT — решение для предоставления услуг IPv4 в сетях, использующих только IPv6» . Т-Мобайл США . Архивировано из оригинала 12 ноября 2020 года . Проверено 5 августа 2013 г.
  19. ^ «Пример: T-Mobile в США переходит только на IPv6, используя 464XLAT» . Интернет-сообщество . 13 июня 2014 года. Архивировано из оригинала 4 февраля 2024 года . Проверено 15 января 2023 г.
  20. ^ Твардовская, Марта (6 января 2015 г.). «Orange Polska запустила первое в мире инновационное решение IPv6 с помощью SoftAtHome» . Деловой провод . Архивировано из оригинала 15 января 2023 г. Проверено 15 января 2023 г.
  21. ^ «Беспроводная поддержка Telstra IPv6 — один стек IPv6» . 6 февраля 2020 года. Архивировано из оригинала 12 июня 2023 года . Проверено 12 июня 2023 г.
  22. ^ Утопи, Дэн. «Что такое Android CLAT?» . Заметки Дэна . Архивировано из оригинала 17 декабря 2022 года . Проверено 15 января 2023 г.
  23. ^ Хэви, Дэниел; Баласубраманян, Правин (14 февраля 2019 г.). «Основные функции сетевого стека в обновлении Creators Update для Windows 10» . Microsoft Сетевой блог . Архивировано из оригинала 1 февраля 2023 года . Проверено 15 января 2023 г.
  24. ^ «Windows 11 планирует расширить поддержку CLAT» . Microsoft Сетевой блог . Архивировано из оригинала 8 марта 2024 года . Проверено 7 марта 2024 г.
  25. ^ «Твиттер» . Проверено 27 июня 2022 г.
  26. ^ «[v6ops] iOS12 только для IPv6» . Проверено 5 ноября 2018 г.
  27. ^ ван Бейнум, Ильич (16 июня 2015 г.). «Apple — разработчикам iOS: скоро появится услуга сотовой связи только с IPv6, подготовьте свои приложения» . Арс Техника . Архивировано из оригинала 28 июня 2016 г. Проверено 2 июля 2016 г.
  28. ^ Андерсон, Торе (20 мая 2019 г.). "кладд" . Гитхаб . Архивировано из оригинала 17 декабря 2022 года . Проверено 15 января 2023 г.
  29. ^ «Пакет OpenWrt Wiki: 464xlat» . OpenWrt . Проверено 1 апреля 2024 г.
  30. ^ Баой, Данило Г. (19 июня 2021 г.). «Примечания к выпуску FreeBSD 12.1-RELEASE» . FreeBSD . Архивировано из оригинала 15 января 2023 года . Проверено 15 января 2023 г.
  31. ^ А. Дюран; Р. Дромс; Дж. Вудятт; Ю. Ли (август 2011 г.). Развертывание широкополосной связи Dual-Stack Lite после исчерпания IPv4 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6333 . ISSN   2070-1721 . RFC 6333 . Предлагаемый стандарт.
  32. ^ Ю. Цюй; В. Сан; М. Букадер; Т. Цоу; Ю. Ли; И. Фаррер (июль 2015 г.). Облегченный 4over6: расширение архитектуры Dual-Stack Lite . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC7596 . ISSN   2070-1721 . РФК 7596 . Предлагаемый стандарт.
  33. ^ Ле Фошёр, Франсуа; Розен, Эрик (май 2009 г.). Рекламирование информации о доступности сетевого уровня IPv4 с помощью следующего перехода IPv6 . дои : 10.17487/RFC5549 . РФК 5549 .
  34. ^ Хробочек, Юлиуш (май 2022 г.). Маршруты Pv4 со следующим переходом IPv6 в протоколе маршрутизации Babel . дои : 10.17487/RFC9229 . РФК 9229 .
  35. ^ Раммхольд, Андреас (15 декабря 2020 г.). «[RFC] Babel: добавлена ​​поддержка v4viav6» . Демон интернет-маршрутизации BIRD . Архивировано из оригинала 29 декабря 2022 г. Проверено 15 января 2023 г.
  36. ^ Хробочек, Юлиуш (5 мая 2022 г.). «[Пользователи Babel] ОБЪЯВЛЯЮ: babyeld-1.12» . Списки Debian Alioth . Архивировано из оригинала 29 декабря 2022 г. Проверено 15 января 2023 г.
  37. ^ Марк Таунсли (24 сентября 2012 г.). «Сопоставление адреса + порта» (PDF) . Циско. Архивировано (PDF) из оригинала 29 декабря 2022 г. Проверено 25 сентября 2012 г.
  38. ^ С. Ли; К. Бао; О. Троан; С. Мацусима; Т. Мураками (июль 2015 г.). В. Дек (ред.). Сопоставление адреса и порта с использованием трансляции (MAP-T) . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7599 . ISSN   2070-1721 . РФК 7599 . Предлагаемый стандарт.
  39. ^ В. Декабрь; С. Ли; К. Бао; С. Мацусима; Т. Мураками (июль 2015 г.). О. Троан; Т. Тейлор (ред.). Сопоставление адреса и порта с инкапсуляцией (MAP-E) . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7597 . ISSN   2070-1721 . РФК 7597 . Предлагаемый стандарт.
  40. ^ Паттерсон, Ричард (май 2021 г.). «Только IPv6 с MAP-T» . День открытых дверей RIPE NCC . Архивировано из оригинала 21 февраля 2023 года . Проверено 1 августа 2023 г.
  41. ^ Р. Депре; Р. Пенно; Ю. Ли; Г. Чен; М. Чен (июль 2015 г.). С. Цзян (ред.). Остаточное развертывание IPv4 через IPv6 — решение без сохранения состояния (4-е место) . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7600 . ISSN   2070-1721 . РФК 7600 . Экспериментальный.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=IPv6_transition_mechanism&oldid=1241019696#Stateless_IP/ICMP_Translation"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 42119c9dba0cc44e465bdbf7c44e2f43__1722424200
URL1:https://arc.ask3.ru/arc/aa/42/43/42119c9dba0cc44e465bdbf7c44e2f43.html
Заголовок, (Title) документа по адресу, URL1:
IPv6 transition mechanism - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)