Технология Teredo для переключения на IPv6 в сетях IPv4

Введение

Технология перехода протокола в компьютерных сетях

В компьютерных сетях Teredo — это переходная технология, обеспечивающая полную связь по IPv6 для хостов, поддерживающих IPv6, находящихся в сети IPv4, но не имеющих прямого подключения к сети IPv6. В отличие от подобных протоколов, таких как 6to4, она способна выполнять свою функцию даже при работе за сетевыми устройствами, выполняющими преобразование сетевых адресов (NAT), например, домашними маршрутизаторами. Teredo работает, используя платформенно-независимый протокол туннелирования, который обеспечивает связь по IPv6 (версия 6 интернет-протокола) путем инкапсуляции пакетов IPv6 в пакеты протокола UDP (протокол пользовательских дейтаграмм IPv4). Teredo маршрутизирует эти пакеты по сети IPv4 и через устройства 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 IPv6 (2001::/32) другим хостам IPv6. Таким образом, реле Teredo получает трафик от хостов IPv6, адресованный любому клиенту Teredo, и пересылает его по UDP/IPv4. Симметрично, оно получает пакеты от клиентов Teredo, адресованные хостам IPv6 через UDP/IPv4, и передает их в сеть IPv6. На практике сетевые администраторы могут настроить частное реле Teredo для своей компании или кампуса. Это обеспечивает короткий путь между их сетью IPv6 и любым клиентом Teredo. Однако для развертывания реле Teredo в масштабе, превышающем одну сеть, требуется возможность экспорта маршрутов BGP IPv6 в другие автономные системы (АС). В отличие от 6to4, где обе стороны соединения могут использовать разные реле, трафик между хостом IPv6 и клиентом Teredo использует одно и то же реле Teredo, а именно ближайшее к сети хоста IPv6. Клиент Teredo не может самостоятельно определить реле (поскольку не может отправлять пакеты IPv6 напрямую). Если ему необходимо установить соединение с хостом IPv6, он отправляет первый пакет через сервер Teredo, который отправляет пакет хосту IPv6, используя адрес Teredo IPv6 клиента. Затем хост IPv6 отвечает как обычно на адрес Teredo IPv6 клиента, что в конечном итоге приводит пакет к реле Teredo, которое устанавливает соединение с клиентом (возможно, используя сервер Teredo для преодоления NAT). Клиент Teredo и хост IPv6 затем используют реле для связи столько, сколько необходимо. Эта конструкция означает, что ни сервер Teredo, ни клиент не должны знать IPv4-адреса каких-либо реле Teredo. Они находят подходящее автоматически через глобальную таблицу маршрутизации IPv6, поскольку все реле Teredo рекламируют сеть 2001::/32. 30 марта 2006 года итальянский провайдер ITGate стал первым AS, который начал рекламировать маршрут к 2001::/32 в IPv6 Интернете, чтобы реализации Teredo, соответствующие RFC 4380, могли быть полностью использованы. С 16 февраля 2007 года он перестал функционировать. В первом квартале 2009 года магистральная сеть IPv6 Hurricane Electric включила 14 реле Teredo в реализации anycast и рекламировала 2001::/32 по всему миру. Реле располагались в Сиэтле, Фримонте, Лос-Анджелесе, Чикаго, Далласе, Торонто, Нью-Йорке, Эшберне, Майами, Лондоне, Париже, Амстердаме, Франкфурте и Гонконге. Ожидается, что крупные сетевые операторы будут поддерживать реле Teredo. Как и в случае с 6to4, остается неясным, насколько хорошо масштабируется служба Teredo, если большая часть хостов в Интернете начнет использовать IPv6 через Teredo в дополнение к IPv4. Хотя Microsoft поддерживала набор серверов Teredo с момента выпуска первого псевдо-туннеля Teredo для Windows XP, она никогда не предоставляла службу ретрансляции Teredo для всего IPv6 Интернета.

A Teredo relay potentially requires much network bandwidth. Also, it must export (advertise) a route toward the Teredo IPv6 prefix (2001::/32) to other IPv6 hosts. That way, the Teredo relay receives traffic from the IPv6 hosts addressed to any Teredo client, and forwards it over UDP/IPv4. Symmetrically, it receives packets from Teredo clients addressed to native IPv6 hosts over UDP/IPv4 and injects those into the native IPv6 network. In practice, network administrators can set up a private Teredo relay for their company or campus. This provides a short path between their IPv6 network and any Teredo client. However, setting up a Teredo relay on a scale beyond that of a single network requires the ability to export BGP IPv6 routes to the other autonomous systems (AS's). Unlike 6to4, where the two halves of a connection can use different relays, traffic between a native IPv6 host and a Teredo client uses the same Teredo relay, namely the one closest to the native IPv6 host network wise. The Teredo client cannot localize a relay by itself (since it cannot send IPv6 packets by itself). If it needs to initiate a connection to a native IPv6 host, it sends the first packet through the Teredo server, which sends a packet to the native IPv6 host using the client's Teredo IPv6 address. The native IPv6 host then responds as usual to the client's Teredo IPv6 address, which eventually causes the packet to find a Teredo relay, which initiates a connection to the client (possibly using the Teredo server for NAT piercing). The Teredo Client and native IPv6 host then use the relay for communication as long as they need to. This design means that neither the Teredo server nor client needs to know the IPv4 address of any Teredo relays. They find a suitable one automatically via the global IPv6 routing table, since all Teredo relays advertise the network 2001::/32. On March 30, 2006, Italian ISP ITGate was the first AS to start advertising a route toward 2001::/32 on the IPv6 Internet, so that RFC 4380 compliant Teredo implementations would be fully usable. As of 16 February 2007, it is no longer functional. In Q1 2009, IPv6 backbone Hurricane Electric enabled 14 Teredo relays in an anycast implementation and advertising 2001::/32 globally. The relays were located in Seattle, Fremont, Los Angeles, Chicago, Dallas, Toronto, New York, Ashburn, Miami, London, Paris, Amsterdam, Frankfurt, and Hong Kong. It is expected that large network operators will maintain Teredo relays. As with 6to4, it remains unclear how well the Teredo service will scale up if a large proportion of Internet hosts start using IPv6 through Teredo in addition to IPv4. While Microsoft has operated a set of Teredo servers since they released the first Teredo pseudo tunnel for Windows XP, they have never provided a Teredo relay service for the IPv6 Internet as a whole.

Ограничения

Teredo не совместим со всеми устройствами NAT. Используя терминологию RFC 3489, он поддерживает NAT с полным конусом, ограниченным и ограниченным по портам типом, но не поддерживает симметричные NAT. Оригинальная спецификация Shipworm, которая легла в основу финального протокола Teredo, также поддерживала симметричные NAT, но от этой поддержки отказались из соображений безопасности. Позже сотрудники Национального университета Чьяо Тунга на Тайване предложили SymTeredo, который расширил оригинальный протокол Teredo для поддержки симметричных NAT, а реализации Microsoft и Miredo включают некоторые неопределенные нестандартные расширения для улучшения поддержки симметричных NAT. Однако, соединение между клиентом Teredo, находящимся за симметричным NAT, и клиентом Teredo, находящимся за NAT с ограниченным по портам или симметричным типом, остаётся, по всей видимости, невозможным. Действительно, Teredo предполагает, что при обмене инкапсулированными IPv6 пакетами между двумя клиентами, используемые отображённые/внешние номера UDP портов будут такими же, как те, которые использовались для связи с сервером Teredo (и для построения IPv6 адреса Teredo). Без этого предположения установить прямое соединение между двумя клиентами было бы невозможно, и потребовалось бы дорогостоящее реле для выполнения маршрутизации треугольником. Реализация 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-трафика невидимым для программного обеспечения анализа пакетов, облегчая распространение вредоносного ПО. Наконец, Teredo подвергает IPv6-стек и программное обеспечение туннелирования атакам, если в них имеются удалённо эксплуатируемые уязвимости. Для снижения поверхности атаки в IPv6-стеке Microsoft предусмотрена опция сокета "уровень защиты". Она позволяет приложениям указывать, от каких источников они готовы принимать IPv6-трафик: из туннеля Teredo, из любого источника, кроме Teredo (по умолчанию), или только из локальной сети. Протокол Teredo также включает в свои пакеты данных подробную информацию о конечной точке туннеля. Эта информация может помочь злоумышленникам, повысив вероятность атаки и/или снизив необходимые усилия.

Блокировка, фильтрация и защитные экраны

Для корректной работы псевдотуннеля Teredo исходящие UDP-пакеты на порт 3544 не должны фильтроваться. Более того, ответы на эти пакеты (то есть, "запрашиваемый трафик") также не должны фильтроваться. Это соответствует типичной конфигурации NAT и его функциональности stateful firewall. Программное обеспечение Teredo-туннелирования сообщает о критической ошибке и прекращает работу, если исходящий IPv4 UDP-трафик блокируется.

DoS через маршрутизационные петли

В 2010 году были обнаружены новые методы осуществления атак типа «отказ в обслуживании» посредством маршрутизационных петель с использованием туннелей Teredo. Их относительно легко предотвратить.

Использование по умолчанию в MS-Windows

Microsoft Windows, начиная с Windows 10 версии 1803 и более поздних, отключает Teredo по умолчанию. При необходимости эту устаревшую технологию можно включить с помощью командной строки или групповой политики.

Выбор названия

Первоначальное прозвище протокола туннелирования Teredo было "Корабный червь". Идея заключалась в том, что протокол будет проникать сквозь устройства NAT, подобно тому, как корабельный червь (вид морского моллюска, прокладывающего ходы в дереве) проделывает тоннели в древесине. Корабные черви стали причиной гибели многих деревянных корпусов судов. В первоначальном варианте Кристиан Хуитема отметил, что корабельный червь "выживает только в относительно чистой и незагрязненной воде; его недавнее возвращение в несколько портов Северной Америки свидетельствует об их вновь обретенной чистоте. Сервис Shipworm, в свою очередь, должен способствовать восстановлению прозрачности Интернета". Чтобы избежать путаницы с компьютерными червями, Хуитема позже изменил название протокола с Shipworm на Teredo, взяв за основу научное название рода корабельного червя – Teredo navalis.