AllInfo
Main: Info Blog Temp Mail


unix 2018-06-28 08-50-08

Все технологии туннелирования IPv6 понятным языком

В этой статье я хотел бы рассмотреть все актуальные способы туннелирования IPv6 через готовую IPv4-инфраструктуру, описанные в RFC 7059. Один из немногих RFC, написанных понятным человеческим языком, кстати.
Вы все еще сомневаетесь, нужен ли вам IPv6?
У всех устройств белый IP. Никаких NAT, никаких пробросов портов
Выше скорость скачивания торрентов за счет пиров, имеющих IPv6-адрес, но с «серым» IPv4.
В некоторых случаях, выше скорость доступа к сайтам (YouTube через IPv6 не тормозит по вечерам)
Доступ к сайтам, заблокированным в РФ, имеющим IPv6-адрес (nnm-club, например)
Но это еще не все. Представьте ситуацию, когда у вас сломался DHCP-сервер, а на компьютер в этой сети нужно побыстрее бы зайти. Он не получает IP-адрес, вы не можете на него зайти. Беда. Однако, если у вас был просто включен IPv6 — даже не настроен — то вы можете просто пропинговать магический адрес ff02::1, получить ответ от этого компьютера (т.к. у него в любом случае будет link-local IPv6-адрес!) и зайти на него.

Ну да ладно, перейдем к туннелированию.

6in4
Один из самых старых способов туннелирования, придуманный аж в 1996 году, и до сих пор очень популярный. Такие крупные туннель-брокеры, как Hurricane Electric, gogo6 и SIXXS используют его. Использует протокол 41 (не путайте с портом!) и не работает через NAT. Поддерживается всеми современными ОС из коробки.

6over4
По сути, 6over4 нельзя назвать туннелем в привычном смысле этого слова. Он использует IPv4 как виртуальный ethernet для IPv6, например, multicast-адрес ff02::1 превращается в IPv4 multicast-адрес 239.192.0.1. Протокол поддерживает генерацию Link-Local адреса, Neighbor Discovery и конфигурируется автоматически. Из-за того, что все роутеры в сети должны поддерживать Multicast, протокол не стал популярным. Поддержка в современных ОС отсутствует или ограничена.

6to4
6to4 превратит ваш IPv4-адрес в IPv6 /48-подсеть. По сути, это тот же 6in4, но с фиксированным anycast IPv4 адресом: 192.88.99.1. Протокол полностью автоконфигурируемый, ручная настройка невозможна. Легок в настройке. Минус в том, что ваш IPv4-адрес можно узнать из IPv6-адреса, и то, что вы не можете выбрать сервер, через который происходит туннелирование. В некоторых случаях, вы вообще не сможете узнать, кому этот сервер принадлежит. Использует специальный префикс 2002::/16. Не работает через NAT.

6rd
Этот протокол основан на 6to4, только предназначен для развертывания внутри большой организации или ISP. Не использует префикс 2002::/16, а использует обычный диапазон адресов, выданный вашему провайдеру. Может автоматически настраиваться разными способами, самый популярный — через DHCPv4 специальным параметром.

AYIYA
Расшифровывается как Anything In Anything, этот протокол может инкапсулировать, собственно, что-либо во что-либо. Протокол придуман туннель-брокером SIXXS и используется им же. В данный момент, в основном, используется IPv4-UDP-AYIYA-IPv6. Есть поддержка чексумм и авторизации. Работает через NAT.

ISATAP
Этот протокол несколько похож на 6over4, но не использует Multicast. ISATAP не поддерживает Multicast вообще. IPv6-адреса генерируются на основе IPv4-адреса. Предполагается, что IPv4-адрес будет уникальным, поэтому не работает с NAT. Связь с ISATAP-хостами возможна только в том случае, если у вас тоже настроен ISATAP. Поддерживается современными ОС.

Teredo
Крайне популярный способ туннелирования, не требующий особых настроек. В Windows (начиная с Vista) настроен и включен по умолчанию, в Linux поднимается за несколько секунд с использованием Miredo. От вас требуется указать Teredo-сервер (или использовать сервер по умолчанию), все остальное сконфигурируется автоматически. Работает через NAT, однако, с нюансами (зависит как от типа NAT, так и от имплементации на стороне Teredo-сервера).

6a44
Протокол сделан под влиянием Teredo, но предназначен для развертывания средствами ISP. Аналогично 6rd и 6to4, клиентам выдается IPv6-префикс провайдера, а не IPv6-префикс Teredo. Похоже, пока нигде не поддерживается.

6bed4
Peer-to-Peer IPv6 on Any Internetwork. 6bed4 предназначен для создания p2p IPv6-сети внутри IPv4-сети, не запрещающей p2p-соединения между хостами. Протокол является гибридом 6to4 и Teredo: IPv6-адрес формируется из IPv4 и UDP-порта, если p2p-соединение невозможно, используется релей, который может быть запущен ISP или просто сторонней организацией. Работает через NAT, поддерживает как автоконфигурирование, так и ручную настройку.

LISP
Locator/ID Separation Protocol ставит основной целью разделить зависимость IPv6-адреса от местоположения клиента. Используя этот протокол, вы можете использовать свой (предположим, домашний) IPv6-адрес вне вашей сети, без проксирования трафика. По концепции, схож с Proxy Mobile IPv6. Сам протокол достаточно сложный и использовать его исключительно для туннелирования достаточно глупо. Не работает через NAT. Поддерживается Cisco, Linux и FreeBSD.

SEAL
Subnetwork Encapsulation and Adaptation Layer. Совсем свежий протокол, draft появился в октябре 2013. Поддерживает несколько IPv4-линков, и, соответственно, multihoming. Есть аутентификация и anti-replay механизм. SEAL Control Message Protocol используется для обменом служебными данными между хостами.

Табличка

Протокол Туннелей на IPv4-адрес IPv6-хостов на туннель Публичный IPv4 NAT-совместимость P2P Gateway принадлежит
6to4 Один Много Требуется Нет Глобальный ISP или публичный
LISP Один Много Требуется Нет Настраивается ISP или Tunnel Broker
6rd Один Много Не требуется Нет Внутри домена ISP
6in4 Один Много Не требуется** Ограниченная Нет ISP или Tunnel Broker
Teredo Много Один Не требуется Да* Глобальный Публичный релей
6bed4 Много Много Не требуется Да Глобальный ISP, Tunnel Broker или публичный релей
6a44 Много Много Не требуется Да Внутри домена ISP
AYIYA Много Много Не требуется Да Нет ISP или Tunnel Broker
SEAL Много Много Не требуется Да Настраивается ISP или Tunnel Broker

* ограниченная поддержка, с некоторыми типами NAT может не работать
** внешний IPv4 не требуется, если релей поднят ISP

3.12.73.221 / 2024-12-22_20-49-59 UTC.