Туннелирование Teredo

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

В компьютерных сетях 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 выполняет несколько функций:

  1. Диагностирует подключение UDP через IPv4 (UDPv4) и обнаруживает тип имеющегося NAT (используя упрощенную замену протокола STUN )
  2. Назначает глобально маршрутизируемый уникальный адрес IPv6 каждому хосту, использующему его
  3. Инкапсулирует пакеты IPv6 в датаграммы UDPv4 для передачи по сети IPv4 (включая обход NAT )
  4. Маршрутизирует трафик между хостами Teredo и собственными (или иными не-Teredo) хостами IPv6

Типы узлов

Teredo определяет несколько различных типов узлов: [1]

Клиент Teredo
Хост, который имеет подключение IPv4 к Интернету из-за NAT и использует протокол туннелирования Teredo для доступа к Интернету IPv6. Клиентам Teredo назначается адрес IPv6, который начинается с префикса Teredo ( 2001::/32). [2]
Teredo-сервер
Известный хост, используемый для начальной настройки туннеля Teredo. Сервер Teredo никогда не пересылает трафик для клиента (кроме пингов IPv6) и поэтому имеет скромные требования к пропускной способности (не более нескольких сотен бит в секунду на клиента), [ необходима цитата ] , что означает, что один сервер может поддерживать множество клиентов. Кроме того, сервер Teredo может быть реализован полностью без сохранения состояния , таким образом используя тот же объем памяти независимо от того, сколько клиентов он поддерживает.
реле Тередо
Удаленный конец туннеля Teredo. Ретранслятор Teredo должен пересылать все данные от имени клиентов Teredo, которых он обслуживает, за исключением прямых обменов между клиентами Teredo и клиентами Teredo. Поэтому ретранслятору требуется большая пропускная способность, и он может поддерживать только ограниченное количество одновременных клиентов. Каждый ретранслятор Teredo обслуживает ряд хостов IPv6 (например, один кампус или компанию, интернет-провайдера или целую сеть оператора, или даже весь Интернет IPv6 ); он пересылает трафик между любыми клиентами Teredo и любым хостом в пределах указанного диапазона.
Ретрансляция, специфичная для хоста Teredo
Ретранслятор Teredo, диапазон обслуживания которого ограничен самим хостом, на котором он запущен. Таким образом, у него нет особых требований к пропускной способности или маршрутизации. Компьютер с ретранслятором, специфичным для хоста, использует Teredo для связи с клиентами Teredo, но придерживается своего основного поставщика услуг IPv6 для доступа к остальной части Интернета IPv6.

IPv6-адресация

Каждому клиенту Teredo назначается публичный адрес IPv6 , который строится следующим образом (старший бит имеет номер 0):

  • Биты с 0 по 31 содержат префикс Teredo (2001::/32).
  • Биты 32–63 содержат основной IPv4-адрес используемого сервера Teredo.
  • Биты с 64 по 79 содержат некоторые флаги и другие биты; формат этих 16 бит, начиная со старшего бита, — «CRAAAAUG AAAAAAAA». Бит «C» был установлен в 1, если клиент Teredo находится за конусным NAT , и в 0 в противном случае, но RFC 5991 изменил его так, чтобы он всегда был равен 0, чтобы не раскрывать этот факт посторонним лицам. Бит «R» в настоящее время не назначен и должен отправляться как 0. Биты «U» и «G» установлены в 0, чтобы эмулировать биты «Universal/local» и «Group/individual» в MAC-адресах . 12 бит «A» были равны 0 в исходной спецификации RFC 4380, но были изменены на случайные биты, выбранные клиентом Teredo в RFC 5991, чтобы предоставить узлу Teredo дополнительную защиту от сканирующих атак на основе IPv6.
  • Биты с 80 по 95 содержат замаскированный номер порта UDP. Это номер порта, который NAT сопоставляет клиенту Teredo, причем все биты инвертированы.
  • Биты с 96 по 127 содержат замаскированный адрес IPv4. Это публичный адрес IPv4 NAT со всеми инвертированными битами.
Таблица адресации Teredo IPv6
Биты0 - 3132 - 6364 - 7980 - 9596 - 127
Длина32 бита32 бита16 бит16 бит32 бита
ОписаниеПрефиксTeredo
сервер IPv4
ФлагиСкрытый
порт UDP
Запутанный клиентский
публичный IPv4

Например, адрес IPv6 2001:0000:4136:e378:8000:63bf:3fff:fdd2 относится к клиенту Teredo, который:

  • Использует сервер Teredo по адресу 65.54.227.120 (4136e378 в шестнадцатеричном формате )
  • Находится за коническим NAT, и клиент не полностью соответствует RFC 5991 (установлен бит 64)
  • Вероятно (99,98%) не соответствует RFC 5991 (все 12 случайных бит равны 0, что случается реже, чем в 0,025% случаев)
  • Использует сопоставленный UDP порт 40000 на своем NAT (в шестнадцатеричном формате 63bf не равно 9c40 или десятичному числу 40000)
  • Имеет публичный адрес IPv4 NAT 192.0.2.45 (не 3ffffdd2 равно c000022d, то есть 192.0.2.45)
Пример таблицы Teredo IPv6
Биты0 - 3132 - 6364 - 7980 - 9596 - 127
Длина32 бита32 бита16 бит16 бит32 бита
ОписаниеПрефиксTeredo
сервер IPv4
ФлагиСкрытый
порт UDP
Запутанный клиентский
публичный IPv4
Часть2001:00004136:е378800063бф3fff:fdd2
Раскодировано65.54.227.120конус NAT40000192.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 являются:

  • Возможность отправки пакетов ICMPv6 с исходным адресом, принадлежащим префиксу Teredo
  • Два отдельных публичных адреса IPv4. Хотя это и не прописано в официальной спецификации, клиенты Microsoft Windows ожидают, что оба адреса будут последовательными — второй адрес IPv4 предназначен для обнаружения NAT

Публичные серверы Teredo:

  • teredo.trex.fi (Финляндия)

Бывшие публичные серверы Teredo:

  • teredo.remlab.net / teredo-debian.remlab.net (Германия), теперь перенаправляет на teredo.trex.fi [3]

Реле

Ретранслятор 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 блокируется.

DoS-атаки через петли маршрутизации

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

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

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

Реализации

В настоящее время доступно несколько реализаций Teredo:

  • Windows XP SP2 включает в себя клиентский и хост-специфичный ретранслятор (также в Advanced Networking Pack для Service Pack 1).
  • Windows Server 2003 имеет ретранслятор и сервер, предоставляемые в рамках программы Microsoft Beta.
  • Windows Vista и Windows 7 имеют встроенную поддержку Teredo с неопределенным расширением для симметричного обхода NAT. Однако, если присутствуют только link-local и Teredo-адрес, эти операционные системы не пытаются разрешить записи IPv6 DNS AAAA, если присутствует запись DNS A, в этом случае они используют IPv4. Поэтому только буквальные URL-адреса IPv6 обычно используют Teredo. [12] Это поведение можно изменить в реестре .
  • Windows 10 версии 1803 и более поздние версии отключают Teredo по умолчанию. При необходимости эту переходную технологию можно включить с помощью команды CLI или групповой политики . [11]
  • Miredo — это клиент, ретранслятор и сервер для Linux , *BSD и Mac OS X.
  • ng_teredo — это ретранслятор и сервер на основе netgraph для FreeBSD от LIP6 University и 6WIND. [13] [ необходима ссылка ]
  • NICI-Teredo — это ретранслятор для ядра Linux и пользовательский сервер Teredo, разработанный в Национальном университете Цзяотун. [14] [ необходима ссылка ]

Выбор имени

Первоначальное прозвище протокола туннелирования Teredo было Shipworm . Идея заключалась в том, что протокол будет проникать через устройства NAT, подобно тому, как корабельный червь (вид морского моллюска, сверлящего древесину) прокладывает туннели через древесину. Корабельные черви были ответственны за потерю многих деревянных корпусов. Кристиан Уитема в первоначальном проекте отметил, что корабельный червь «выживает только в относительно чистой и незагрязненной воде; его недавнее возвращение в несколько североамериканских гаваней является свидетельством их недавно восстановленной чистоты. Служба Shipworm должна, в свою очередь, способствовать [ sic ] недавно восстановленной прозрачности Интернета». [15]

Чтобы избежать путаницы с компьютерными червями , [16] Уитема позже изменил название протокола с Shipworm на Teredo , в честь названия рода корабельного червя Teredo navalis . [16]

Ссылки

  1. ^ Шарма, Вишал; Кумар, Раджеш (2017). «Безопасная передача данных между БПЛА и наземными сетями ad hoc на основе туннелирования Teredo». Международный журнал систем связи . 30 (7): e3144. doi :10.1002/dac.3144. ISSN  1099-1131. S2CID  5263153.
  2. ^ "Teredo Addresses (Windows)". msdn.microsoft.com . Архивировано из оригинала 2016-12-23 . Получено 2014-12-02 .
  3. ^ Rémi Denis-Courmont (5 июня 2021 г.). "Miredo : News". Архивировано из оригинала 2022-07-17 . Получено 2022-07-17 . На данный момент teredo.remlab.net будет псевдонимом публичного сервера Teredo, предоставленного региональной биржей TREX в финском городе Тампере.
  4. ^ "IT.Gate | Технологические услуги - IT.Gate". itgate.it . Архивировано из оригинала 14 июня 2021 г. . Получено 22 сентября 2019 г. .
  5. ^ Леви, Мартин (28 мая 2009 г.). «Опыт Hurricane Electric в развертывании реле Teredo и 6to4» (PDF) . Конференция LACNIC-XII/FLIP6 2009, Панама-Сити, Панама. Архивировано (PDF) из оригинала 11 апреля 2015 г. . Получено 29 декабря 2012 г. .
  6. Huitema, Christian (12 июля 2001 г.). Shipworm: туннелирование IPv6 по UDP через NAT.Архивировано 4 января 2021 г. на Wayback Machine
  7. ^ Хуан, Шианг-Мин; Ву, Куинси; Линь, И-Бин (май 2006 г.). «Улучшение туннелирования teredo IPv6 для обхода симметричного NAT». IEEE Communications Letters . 10 (5): 408–410. doi :10.1109/LCOMM.2006.1633339. ISSN  1089-7798. Архивировано из оригинала 01.05.2022 . Получено 01.05.2022 .
  8. ^ "Malware Tunneling in IPv6". US-CERT.gov . 22 июня 2012 г. Архивировано из оригинала 2020-08-10 . Получено 2016-09-05 .
  9. ^ «Протоколы туннелирования IPv6: хороши для внедрения, но не так уж хороши для безопасности — блог TrendLabs Security Intelligence». 2009-10-26. Архивировано из оригинала 2016-10-08 . Получено 2016-09-05 .
  10. ^ Gont, Fernando (8 сентября 2010 г.). «Internet-Draft — Teredo routing loops — Mitigating Teredo Rooting Loop Attacks». Ietf Datatracker . ietf.org. стр. 2. Архивировано из оригинала 7 декабря 2021 г. . Получено 9 августа 2021 г. .
  11. ^ ab "Клиенты DirectAccess, использующие туннелирование Teredo, не могут подключиться после обновления до Windows 10". Microsoft Docs . 2020-12-07. Архивировано из оригинала 2021-01-14 . Получено 2021-01-12 .
  12. ^ "ISP Column - May 2011". potaroo.net . Архивировано из оригинала 1 ноября 2019 . Получено 22 сентября 2019 .
  13. ^ Кабасанов, Константин; Жарден, Винсент. (22 октября 2003 г.). Teredo для FreeBSD. Архивировано 6 марта 2005 г. на сайте Wayback Machine www-rp.lip6.fr.
  14. ^ "Соломон, Аарон". (29 ноября 2004 г.). NICI-Teredo Архивировано 29 августа 2021 г. на Wayback Machine . Sourceforge.
  15. ^ Huitema, Christian (2001-08-25). "Shipworm: Tunneling IPv6 over UDP through NATs (draft 00 of 08)". Ietf Datatracker . Internet Engineering Task Force (IETF). Архивировано из оригинала 2021-08-29 . Получено 2021-08-09 .
  16. ^ ab Huitema, Christian (2001-12-19). "Переименование Shipworm в Teredo?". Почтовая рассылка IETF NGTrans . Internet Engineering Task Force (IETF). Архивировано из оригинала 8 января 2018 г.
  • Обзор Teredo на Microsoft TechNet
  • Текущие маршруты anycast Teredo BGP
  • Teredo: Туннелирование IPv6 через UDP с помощью трансляции сетевых адресов (NAT) . RFC 4380, C. Huitema. Февраль 2006 г.
  • JavaScript Teredo-IP-калькулятор адресов
Взято с "https://en.wikipedia.org/w/index.php?title=Teredo_tunneling&oldid=1243268560"