Механизмы перехода IPv6 |
---|
Стандарты Трек |
Экспериментальный |
Информационный |
Черновики |
Устаревший |
В компьютерных сетях Teredo — это технология перехода Microsoft , которая обеспечивает полное подключение IPv6 для хостов с поддержкой IPv6, которые находятся в Интернете IPv4 , но не имеют собственного подключения к сети IPv6. В отличие от похожих протоколов, таких как 6to4 , он может выполнять свою функцию даже из-за устройств трансляции сетевых адресов (NAT), таких как домашние маршрутизаторы.
Teredo работает с использованием платформенно-независимого протокола туннелирования , который обеспечивает подключение IPv6 (Internet Protocol версии 6) путем инкапсуляции пакетов датаграмм IPv6 в пакеты IPv4 User Datagram Protocol (UDP). Teredo направляет эти датаграммы в IPv4 Internet и через устройства NAT. Узлы Teredo в других местах сети IPv6 (называемые ретрансляторами Teredo ) получают пакеты, распаковывают их и передают дальше.
Teredo — это временная мера. В долгосрочной перспективе все хосты IPv6 должны использовать собственное подключение IPv6. Teredo следует отключить, когда станет доступно собственное подключение IPv6. Кристиан Уитема разработал Teredo в Microsoft , а IETF стандартизировал его как RFC 4380. Сервер Teredo прослушивает порт UDP 3544 .
Для 6to4 , наиболее распространенного протокола туннелирования IPv6 через IPv4, требуется, чтобы конечная точка туннеля имела публичный адрес IPv4. Однако многие хосты в настоящее время подключаются к Интернету IPv4 через одно или несколько устройств NAT, как правило, из-за нехватки адресов IPv4 . В такой ситуации единственный доступный публичный адрес IPv4 назначается устройству NAT, а конечная точка туннеля 6to4 должна быть реализована на самом устройстве NAT. Проблема в том, что многие устройства NAT, развернутые в настоящее время, не могут быть обновлены для реализации 6to4 по техническим или экономическим причинам.
Teredo устраняет эту проблему, инкапсулируя пакеты IPv6 в датаграммы UDP/IPv4, которые большинство NAT могут пересылать должным образом. Таким образом, хосты с поддержкой IPv6 за NAT могут служить конечными точками туннеля Teredo, даже если у них нет выделенного публичного адреса IPv4. По сути, хост, реализующий Teredo, может получить подключение IPv6 без взаимодействия со стороны локальной сетевой среды.
В долгосрочной перспективе все хосты IPv6 должны использовать собственное подключение IPv6. Временный протокол Teredo включает положения для процедуры заката : реализация Teredo должна предоставить способ прекратить использование подключения Teredo, когда IPv6 станет зрелым и подключение станет доступным с использованием менее хрупкого механизма. По состоянию на IETF89 [ необходимо разъяснение ] Microsoft планирует деактивировать свои серверы Teredo для клиентов Windows в первой половине 2014 года [ требуется обновление ] (точная дата будет объявлена), и поощрять деактивацию публично управляемых реле Teredo.
Протокол Teredo выполняет несколько функций:
Teredo определяет несколько различных типов узлов: [1]
2001::/32
). [2]Каждому клиенту Teredo назначается публичный адрес IPv6 , который строится следующим образом (старший бит имеет номер 0):
Биты | 0 - 31 | 32 - 63 | 64 - 79 | 80 - 95 | 96 - 127 |
---|---|---|---|---|---|
Длина | 32 бита | 32 бита | 16 бит | 16 бит | 32 бита |
Описание | Префикс | Teredo сервер IPv4 | Флаги | Скрытый порт UDP | Запутанный клиентский публичный IPv4 |
Например, адрес IPv6 2001:0000:4136:e378:8000:63bf:3fff:fdd2 относится к клиенту Teredo, который:
Биты | 0 - 31 | 32 - 63 | 64 - 79 | 80 - 95 | 96 - 127 |
---|---|---|---|---|---|
Длина | 32 бита | 32 бита | 16 бит | 16 бит | 32 бита |
Описание | Префикс | Teredo сервер IPv4 | Флаги | Скрытый порт UDP | Запутанный клиентский публичный IPv4 |
Часть | 2001:0000 | 4136:е378 | 8000 | 63бф | 3fff:fdd2 |
Раскодировано | 65.54.227.120 | конус NAT | 40000 | 192.0.2.45 |
Клиенты Teredo используют серверы Teredo для автоматического определения типа NAT, за которым они находятся (если таковые имеются), с помощью упрощенной процедуры квалификации , подобной STUN . Клиенты Teredo также поддерживают привязку своего NAT к своему серверу Teredo, отправляя пакет UDP с регулярными интервалами. Это гарантирует, что сервер всегда может связаться с любым из своих клиентов, что требуется для правильной работы дырокола NAT .
Если ретранслятор Teredo (или другой клиент Teredo) должен отправить пакет IPv6 клиенту Teredo, он сначала отправляет пакет Teredo bubble на сервер Teredo клиента, IP-адрес которого он выводит из адреса Teredo IPv6 клиента Teredo. Затем сервер пересылает пузырь клиенту , поэтому программное обеспечение клиента Teredo знает, что оно должно выполнить дырокол в направлении ретранслятора Teredo.
Серверы Teredo также могут передавать пакеты ICMPv6 от клиентов Teredo в направлении IPv6 Интернета. На практике, когда клиент Teredo хочет связаться с собственным узлом IPv6, он должен найти соответствующий ретранслятор Teredo, т. е ., на какой публичный номер порта IPv4 и UDP отправлять инкапсулированные пакеты IPv6. Для этого клиент создает запрос ICMPv6 Echo Request ( ping ) в направлении узла IPv6 и отправляет его через свой настроенный сервер Teredo. Сервер Teredo декапсулирует ping в IPv6 Интернет, так что ping в конечном итоге должен достичь узла IPv6. Затем узел IPv6 должен ответить ответом ICMPv6 Echo Reply, как предписано RFC 2460. Этот ответный пакет направляется ближайшему ретранслятору Teredo, который — в конечном итоге — пытается связаться с клиентом Teredo.
Поддержание сервера Teredo требует небольшой пропускной способности, поскольку они не участвуют в фактической передаче и приеме пакетов трафика IPv6. Кроме того, это не подразумевает никакого доступа к протоколам маршрутизации Интернета. Единственными требованиями к серверу Teredo являются:
Публичные серверы Teredo:
Бывшие публичные серверы Teredo:
Ретранслятор Teredo потенциально требует большой пропускной способности сети. Кроме того, он должен экспортировать ( объявлять ) маршрут к префиксу Teredo IPv6 (2001::/32) другим хостам IPv6. Таким образом, ретранслятор Teredo получает трафик от хостов IPv6, адресованный любому клиенту Teredo, и пересылает его по UDP/IPv4. Симметрично, он получает пакеты от клиентов Teredo, адресованные собственным хостам IPv6, по UDP/IPv4 и вводит их в собственную сеть IPv6.
На практике администраторы сетей могут настроить частный ретранслятор Teredo для своей компании или кампуса. Это обеспечивает короткий путь между их сетью IPv6 и любым клиентом Teredo. Однако настройка ретранслятора Teredo в масштабе, превышающем масштаб одной сети, требует возможности экспортировать маршруты BGP IPv6 в другие автономные системы (AS).
В отличие от 6to4 , где две половины соединения могут использовать разные ретрансляторы, трафик между собственным хостом IPv6 и клиентом Teredo использует один и тот же ретранслятор Teredo, а именно тот, который ближе всего к собственному хосту IPv6 в сетевом отношении. Клиент Teredo не может локализовать ретранслятор самостоятельно (так как он не может отправлять пакеты IPv6 самостоятельно). Если ему нужно инициировать соединение с собственным хостом IPv6, он отправляет первый пакет через сервер Teredo, который отправляет пакет собственному хосту IPv6, используя IPv6-адрес клиента Teredo. Затем собственный хост IPv6 отвечает как обычно на IPv6-адрес клиента Teredo, что в конечном итоге заставляет пакет найти ретранслятор Teredo, который инициирует соединение с клиентом (возможно, используя сервер Teredo для прокалывания NAT ). Затем клиент Teredo и собственный хост IPv6 используют ретранслятор для связи столько времени, сколько им нужно. Такая конструкция означает, что ни серверу Teredo, ни клиенту не нужно знать IPv4-адрес любого ретранслятора Teredo. Они автоматически находят подходящий адрес через глобальную таблицу маршрутизации IPv6, поскольку все ретрансляторы Teredo объявляют сеть 2001::/32.
30 марта 2006 года итальянский интернет-провайдер ITGate [4] стал первым AS, который начал рекламировать маршрут к 2001::/32 в Интернете IPv6, чтобы обеспечить полную пригодность реализаций Teredo, соответствующих RFC 4380. По состоянию на 16 февраля 2007 года он больше не функционирует.
В первом квартале 2009 года IPv6 backbone Hurricane Electric включила 14 ретрансляторов Teredo [5] в реализацию anycast и рекламу 2001::/32 по всему миру. Ретрансляторы были расположены в Сиэтле , Фремонте , Лос-Анджелесе , Чикаго , Далласе , Торонто , Нью-Йорке , Эшберне , Майами , Лондоне , Париже , Амстердаме , Франкфурте и Гонконге .
Ожидается, что крупные сетевые операторы будут поддерживать ретрансляторы Teredo. Как и в случае с 6to4, остается неясным, насколько хорошо будет масштабироваться служба Teredo, если большая часть интернет-хостов начнет использовать IPv6 через Teredo в дополнение к IPv4. Хотя Microsoft эксплуатировала набор серверов Teredo с тех пор, как выпустила первый псевдотуннель Teredo для Windows XP, они никогда не предоставляли службу ретрансляции Teredo для Интернета IPv6 в целом.
Официально этот механизм был создан для ПК с Microsoft Windows XP и более поздних версий для предоставления IPv6-подключения к клиентам IPv4 путем подключения к ipv6.microsoft.com и работает совместно с IP Helper service и драйвером интерфейса адаптера туннелирования Teredo . Служба также открывает порт UPNP на маршрутизаторе для ретрансляции.
Teredo не совместим со всеми устройствами NAT. Используя терминологию RFC 3489, он поддерживает полноконусные, ограниченные и ограниченные по портам устройства NAT , но не поддерживает симметричные NAT . Оригинальная спецификация Shipworm [6] , которая привела к окончательному протоколу Teredo, также поддерживала симметричные NAT, но отказалась от этого из-за проблем безопасности.
Люди из Национального университета Цзяотун в Тайване позже предложили SymTeredo, [7] который улучшил исходный протокол Teredo для поддержки симметричных NAT, а реализации Microsoft и Miredo реализуют определенные неуказанные нестандартные расширения для улучшения поддержки симметричных NAT. Однако связь между клиентом Teredo за симметричным NAT и клиентом Teredo за ограниченным портом или симметричным NAT остается, по-видимому, невозможной. [ необходима цитата ]
Действительно, Teredo предполагает, что когда два клиента обмениваются инкапсулированными пакетами IPv6, используемые сопоставленные/внешние номера портов UDP будут такими же, как те, которые использовались для связи с сервером Teredo (и построения адреса Teredo IPv6). Без этого предположения было бы невозможно установить прямую связь между двумя клиентами, и для выполнения маршрутизации треугольника пришлось бы использовать дорогостоящий ретранслятор . Реализация Teredo пытается определить тип NAT при запуске и откажется работать, если NAT окажется симметричным. (Это ограничение иногда можно обойти, вручную настроив правило переадресации портов на блоке NAT, для чего требуется административный доступ к устройству).
Teredo может предоставить только один адрес IPv6 на конечную точку туннеля. Таким образом, невозможно использовать один туннель Teredo для соединения нескольких хостов, в отличие от 6to4 и некоторых туннелей IPv6 «точка-точка». Пропускная способность, доступная всем клиентам Teredo в направлении Интернета IPv6, ограничена доступностью ретрансляторов Teredo, которые в этом отношении ничем не отличаются от ретрансляторов 6to4.
6to4 требует публичного адреса IPv4, но предоставляет большой 48-битный префикс IPv6 для каждой конечной точки туннеля и имеет меньшие накладные расходы на инкапсуляцию . Туннели точка-точка могут быть более надежными и более подотчетными, чем Teredo, и обычно предоставляют постоянные адреса IPv6, которые не зависят от адреса IPv4 конечной точки туннеля. Некоторые брокеры туннелей точка-точка также поддерживают инкапсуляцию UDP для обхода NAT (например, протокол AYIYA может это сделать). С другой стороны, туннели точка-точка обычно требуют регистрации. Автоматизированные инструменты (например , AICCU ) упрощают использование туннелей точка-точка.
Teredo увеличивает поверхность атаки , назначая глобально маршрутизируемые адреса IPv6 сетевым хостам за устройствами NAT, которые в противном случае были бы недоступны из Интернета. Поступая так, Teredo потенциально раскрывает любое приложение с поддержкой IPv6 с открытым портом наружу. Инкапсуляция туннелей Teredo также может привести к тому, что содержимое трафика данных IPv6 станет невидимым для программного обеспечения проверки пакетов, что способствует распространению вредоносного ПО. [8] Наконец, Teredo раскрывает стек IPv6 и программное обеспечение туннелирования для атак, если они имеют какую-либо удаленно эксплуатируемую уязвимость.
Для уменьшения поверхности атаки стек Microsoft IPv6 имеет опцию сокета «уровень защиты» . Это позволяет приложениям указывать, из каких источников они готовы принимать трафик IPv6: из туннеля Teredo, из любого места, кроме Teredo (по умолчанию), или только из локальной интрасети .
Протокол Teredo также инкапсулирует подробную информацию о конечной точке туннеля в своих пакетах данных. Эта информация может помочь потенциальным злоумышленникам, увеличивая возможность атаки и/или уменьшая требуемые усилия. [9]
Для правильной работы псевдотуннеля Teredo исходящие пакеты UDP на порт 3544 должны быть нефильтрованными. Более того, ответы на эти пакеты (т. е. «запрошенный трафик») также должны быть нефильтрованными. Это соответствует типичной настройке NAT и его функциональности брандмауэра с отслеживанием состояния. Программное обеспечение туннелирования Teredo сообщает о фатальной ошибке и останавливается, если исходящий трафик IPv4 UDP блокируется.
В 2010 году были раскрыты новые методы создания атак типа «отказ в обслуживании» через петли маршрутизации, использующие туннели Teredo. Их сравнительно легко предотвратить. [10]
Microsoft Windows, начиная с Windows 10, версии 1803 и более поздних версий, отключает Teredo по умолчанию. При необходимости эту переходную технологию можно включить с помощью команды CLI или групповой политики . [11]
В настоящее время доступно несколько реализаций Teredo:
Первоначальное прозвище протокола туннелирования Teredo было Shipworm . Идея заключалась в том, что протокол будет проникать через устройства NAT, подобно тому, как корабельный червь (вид морского моллюска, сверлящего древесину) прокладывает туннели через древесину. Корабельные черви были ответственны за потерю многих деревянных корпусов. Кристиан Уитема в первоначальном проекте отметил, что корабельный червь «выживает только в относительно чистой и незагрязненной воде; его недавнее возвращение в несколько североамериканских гаваней является свидетельством их недавно восстановленной чистоты. Служба Shipworm должна, в свою очередь, способствовать [ sic ] недавно восстановленной прозрачности Интернета». [15]
Чтобы избежать путаницы с компьютерными червями , [16] Уитема позже изменил название протокола с Shipworm на Teredo , в честь названия рода корабельного червя Teredo navalis . [16]
На данный момент teredo.remlab.net будет псевдонимом публичного сервера Teredo, предоставленного региональной биржей TREX в финском городе Тампере.