Teredo-Tunnelbau

Im Bereich der Computernetzwerke ist Teredo eine Microsoft- Übergangstechnologie , die IPv6-fähigen Hosts, die sich im IPv4- Internet befinden, aber keine native Verbindung zu einem IPv6-Netzwerk haben, vollständige IPv6- Konnektivität ermöglicht . Anders als ähnliche Protokolle wie 6to4 kann Teredo seine Funktion sogar hinter NAT-Geräten ( Network Address Translation ) wie Heimroutern erfüllen.

Teredo nutzt ein plattformunabhängiges Tunneling-Protokoll , das IPv6- Konnektivität (Internetprotokoll Version 6) ermöglicht , indem es IPv6 -Datagrammpakete in IPv4- UDP-Pakete ( User Datagram Protocol ) einkapselt . Teredo leitet diese Datagramme über das IPv4-Internet und durch NAT-Geräte. Teredo-Knoten an anderen Stellen im IPv6-Netzwerk (sogenannte Teredo-Relays ) empfangen die Pakete, entkapseln sie und leiten sie weiter.

Teredo ist eine Übergangslösung. Langfristig sollten alle IPv6-Hosts native IPv6-Konnektivität nutzen. Sobald native IPv6-Konnektivität verfügbar ist, sollte Teredo deaktiviert werden. Christian Huitema entwickelte Teredo bei Microsoft , und die IETF standardisierte es als RFC 4380. Der Teredo-Server lauscht auf UDP- Port 3544 .

Für 6to4 , das gängigste IPv6-over-IPv4-Tunneling-Protokoll, ist eine öffentliche IPv4-Adresse am Tunnelendpunkt erforderlich. Viele Hosts greifen jedoch aufgrund von IPv4-Adressknappheit über ein oder mehrere NAT-Geräte auf das IPv4-Internet zu . In solchen Fällen wird die einzige verfügbare öffentliche IPv4-Adresse dem NAT-Gerät zugewiesen, und der 6to4-Tunnelendpunkt muss auf diesem implementiert werden. Das Problem besteht darin, dass viele der aktuell eingesetzten NAT-Geräte aus technischen oder wirtschaftlichen Gründen nicht für 6to4 aufgerüstet werden können.

Teredo behebt dieses Problem, indem es IPv6-Pakete in UDP/IPv4-Datagramme einkapselt, die die meisten NATs korrekt weiterleiten können. Dadurch können IPv6-fähige Hosts hinter NATs als Teredo-Tunnelendpunkte dienen, selbst wenn sie keine dedizierte öffentliche IPv4-Adresse besitzen. Ein Host, der Teredo implementiert, kann somit IPv6-Konnektivität ohne jegliche Unterstützung des lokalen Netzwerks herstellen.

Langfristig sollten alle IPv6-Hosts native IPv6-Konnektivität nutzen. Das temporäre Teredo-Protokoll sieht ein Auslaufverfahren vor : Die Teredo-Implementierung sollte eine Möglichkeit bieten, die Teredo-Konnektivität zu beenden, sobald IPv6 ausgereifter ist und eine stabilere Verbindungstechnologie verfügbar ist. Laut IETF 89 plant Microsoft, seine Teredo-Server für Windows-Clients in der ersten Jahreshälfte 2014 zu deaktivieren (genaues Datum noch offen) und die Deaktivierung öffentlich betriebener Teredo-Relays zu fördern.

Das Teredo-Protokoll erfüllt mehrere Funktionen:

1. Diagnostiziert die UDP-over-IPv4-Konnektivität (UDPv4) und ermittelt die Art des vorhandenen NAT (unter Verwendung eines vereinfachten Ersatzes für das STUN- Protokoll).
2. Weist jedem Host, der es verwendet, eine global routingfähige, eindeutige IPv6-Adresse zu.
3. Kapselt IPv6-Pakete in UDPv4-Datagramme zur Übertragung über ein IPv4-Netzwerk ein (dies schließt NAT-Traversal ein ).
4. Leitet den Datenverkehr zwischen Teredo-Hosts und nativen (oder anderweitig nicht-Teredo-) IPv6-Hosts weiter.

Teredo definiert verschiedene Arten von Knoten: ^{[ 1 ]}

Teredo-Klient

Ein Host, der über IPv4-Konnektivität hinter einem NAT verfügt und das Teredo-Tunneling-Protokoll für den Zugriff auf das IPv6-Internet nutzt. Teredo-Clients erhalten eine IPv6-Adresse, die mit dem Teredo-Präfix beginnt ( 2001::/32). ^{[ 2 ]}

Teredo-Server

Ein bekannter Host, der für die Erstkonfiguration eines Teredo-Tunnels verwendet wird. Ein Teredo-Server leitet (abgesehen von IPv6-Pings) keinen Datenverkehr für den Client weiter und hat daher nur geringe Bandbreitenanforderungen (maximal einige hundert Bit pro Sekunde pro Client). Dadurch kann ein einzelner Server viele Clients unterstützen. Zudem kann ein Teredo-Server vollständig zustandslos implementiert werden und benötigt somit unabhängig von der Anzahl der unterstützten Clients immer denselben Speicherplatz.

Teredo-Staffel

Das entfernte Ende eines Teredo-Tunnels. Ein Teredo-Relay leitet alle Daten der von ihm bedienten Teredo-Clients weiter, mit Ausnahme direkter Teredo-Client-zu-Teredo-Kommunikation. Daher benötigt ein Relay viel Bandbreite und kann nur eine begrenzte Anzahl gleichzeitiger Clients unterstützen. Jedes Teredo-Relay bedient einen Bereich von IPv6-Hosts (z. B. einen einzelnen Campus oder ein Unternehmen, einen Internetdienstanbieter oder ein gesamtes Betreibernetzwerk oder sogar das gesamte IPv6-Internet ); es leitet den Datenverkehr zwischen beliebigen Teredo-Clients und beliebigen Hosts innerhalb dieses Bereichs weiter.

Teredo-Host-spezifisches Relay

Ein Teredo-Relay, dessen Reichweite auf den Host beschränkt ist, auf dem es läuft. Daher hat es keine besonderen Bandbreiten- oder Routing-Anforderungen. Ein Computer mit einem hostspezifischen Relay nutzt Teredo zur Kommunikation mit Teredo-Clients, verwendet aber weiterhin seinen primären IPv6-Verbindungsanbieter, um auf das übrige IPv6-Internet zuzugreifen.

Jedem Teredo-Client wird eine öffentliche IPv6-Adresse zugewiesen , die wie folgt aufgebaut ist (das höherwertige Bit ist mit 0 nummeriert):

• Die Bits 0 bis 31 enthalten das Teredo-Präfix (2001::/32).
• Die Bits 32 bis 63 enthalten die primäre IPv4-Adresse des verwendeten Teredo-Servers.
• Die Bits 64 bis 79 enthalten Flags und weitere Bits; das Format dieser 16 Bits (MSB zuerst) ist „CRAAAAUG AAAAAAAA“. Das „C“-Bit war ursprünglich auf 1 gesetzt, wenn sich der Teredo-Client hinter einem Cone-NAT befand , andernfalls auf 0. RFC 5991 änderte dies jedoch, sodass es immer 0 ist, um diese Information nicht preiszugeben. Das „R“-Bit ist derzeit nicht belegt und sollte als 0 gesendet werden. Die „U“- und „G“-Bits sind auf 0 gesetzt, um die „Universal/Local“- und „Group/Individual“-Bits in MAC-Adressen zu emulieren . Die 12 „A“-Bits waren in der ursprünglichen RFC-4380-Spezifikation 0, wurden aber in RFC 5991 durch vom Teredo-Client zufällig gewählte Bits ersetzt, um den Teredo-Knoten zusätzlich vor IPv6-basierten Scanning-Angriffen zu schützen.
• Die Bits 80 bis 95 enthalten die verschleierte UDP-Portnummer. Dies ist die Portnummer, die das NAT dem Teredo-Client zuordnet, wobei alle Bits invertiert sind.
• Die Bits 96 bis 127 enthalten die verschleierte IPv4-Adresse. Dies ist die öffentliche IPv4-Adresse des NAT, bei der alle Bits invertiert sind.

Beispielsweise verweist die IPv6-Adresse 2001:0000:4136:e378:8000:63bf:3fff:fdd2 auf einen Teredo-Client, der:

• Verwendet den Teredo-Server unter der Adresse 65.54.227.120 (4136e378 in Hexadezimaldarstellung )
• Befindet sich hinter einem Cone-NAT und der Client ist nicht vollständig RFC 5991-konform (Bit 64 ist gesetzt).
• Ist wahrscheinlich (99,98 %) nicht konform mit RFC 5991 (die 12 Zufallsbits sind alle 0, was in weniger als 0,025 % der Fälle vorkommt)
• Verwendet den UDP-Port 40000 auf seinem NAT (hexadezimal, nicht 63bf entspricht 9c40, oder dezimal 40000).
• Besitzt eine öffentliche NAT-IPv4-Adresse von 192.0.2.45 (nicht 3ffffdd2 gleich c000022d, sondern 192.0.2.45)

Teredo-Clients nutzen Teredo-Server, um mithilfe eines vereinfachten, STUN-ähnlichen Qualifizierungsverfahrens automatisch zu erkennen, hinter welchem ​​NAT-Router sie sich befinden (falls vorhanden) . Zudem halten Teredo-Clients die Verbindung zwischen ihrem NAT-Router und dem Teredo-Server aufrecht, indem sie in regelmäßigen Abständen ein UDP-Paket senden. Dadurch wird sichergestellt, dass der Server jederzeit jeden seiner Clients erreichen kann – eine Voraussetzung für die korrekte Funktion des NAT-Hole-Punchings .

Wenn ein Teredo-Relay (oder ein anderer Teredo-Client) ein IPv6-Paket an einen Teredo-Client senden muss, sendet es zunächst ein Teredo-Bubble -Paket an den Teredo-Server des Clients. Dessen IP-Adresse wird aus der IPv6-Adresse des Teredo-Clients abgeleitet. Der Server leitet das Bubble-Paket dann an den Client weiter, sodass die Teredo-Client-Software weiß, dass sie ein Hole Punching zum Teredo-Relay durchführen muss.

Teredo-Server können auch ICMPv6-Pakete von Teredo-Clients ins IPv6-Internet senden. Wenn ein Teredo-Client einen nativen IPv6-Knoten kontaktieren möchte, muss er das entsprechende Teredo-Relay ermitteln, d. h . die öffentliche IPv4-Adresse und den UDP-Port, an den die gekapselten IPv6-Pakete gesendet werden sollen. Dazu erstellt der Client eine ICMPv6-Echo-Anfrage ( Ping ) an den IPv6-Knoten und sendet diese über seinen konfigurierten Teredo-Server. Der Teredo-Server entkapselt den Ping und sendet ihn ins IPv6-Internet, sodass er schließlich den IPv6-Knoten erreichen sollte. Der IPv6-Knoten antwortet dann gemäß RFC 2460 mit einer ICMPv6-Echo-Antwort. Dieses Antwortpaket wird an das nächstgelegene Teredo-Relay weitergeleitet, das schließlich versucht, den Teredo-Client zu kontaktieren.

Der Betrieb eines Teredo-Servers erfordert nur geringe Bandbreite, da dieser nicht an der eigentlichen Übertragung und dem Empfang von IPv6-Datenpaketen beteiligt ist. Außerdem benötigt er keinen Zugriff auf die Routing-Protokolle des Internets. Die einzigen Voraussetzungen für einen Teredo-Server sind:

• Die Fähigkeit, ICMPv6-Pakete mit einer Quelladresse aus dem Teredo-Präfix zu senden
• Zwei unterschiedliche öffentliche IPv4-Adressen. Obwohl dies nicht in der offiziellen Spezifikation aufgeführt ist, erwarten Microsoft Windows-Clients, dass beide Adressen aufeinanderfolgend sind – die zweite IPv4-Adresse dient der NAT-Erkennung.

Öffentliche Teredo-Server:

• win10.ipv6.microsoft.com
• win1910.ipv6.microsoft.com

Ehemalige öffentliche Teredo-Server:

• teredo.remlab.net / teredo-debian.remlab.net (Deutschland), eingestellt seit 2021. ^{[ 3 ]}
• teredo.trex.fi (Finnland), seit 2022 nicht mehr aktiv. ^{[ 4 ]}

Ein Teredo-Relay benötigt unter Umständen viel Netzwerkbandbreite. Außerdem muss es eine Route zum Teredo-IPv6-Präfix (2001::/32) an andere IPv6-Hosts exportieren ( ankündigen ). Dadurch empfängt das Teredo-Relay Datenverkehr von IPv6-Hosts, der an beliebige Teredo-Clients adressiert ist, und leitet ihn über UDP/IPv4 weiter. Umgekehrt empfängt es Pakete von Teredo-Clients, die an native IPv6-Hosts adressiert sind, über UDP/IPv4 und speist diese in das native IPv6-Netzwerk ein.

In der Praxis können Netzwerkadministratoren ein privates Teredo-Relay für ihr Unternehmen oder ihren Campus einrichten. Dadurch wird ein kurzer Pfad zwischen ihrem IPv6-Netzwerk und jedem Teredo-Client bereitgestellt. Die Einrichtung eines Teredo-Relays in einem größeren Umfang als einem einzelnen Netzwerk erfordert jedoch die Möglichkeit, BGP- IPv6-Routen an die anderen autonomen Systeme (AS) zu exportieren.

Anders als bei 6to4 , wo die beiden Seiten einer Verbindung unterschiedliche Relays nutzen können, verwendet der Datenverkehr zwischen einem nativen IPv6-Host und einem Teredo-Client dasselbe Teredo-Relay, nämlich dasjenige, das dem nativen IPv6-Host netzwerkweit am nächsten liegt. Der Teredo-Client kann kein Relay selbst lokalisieren (da er keine IPv6-Pakete selbst senden kann). Wenn er eine Verbindung zu einem nativen IPv6-Host herstellen muss, sendet er das erste Paket über den Teredo-Server, der es dann mit der Teredo-IPv6-Adresse des Clients an den nativen IPv6-Host weiterleitet. Der native IPv6-Host antwortet daraufhin wie gewohnt an die Teredo-IPv6-Adresse des Clients, wodurch das Paket schließlich ein Teredo-Relay findet, das eine Verbindung zum Client herstellt (möglicherweise unter Verwendung des Teredo-Servers für NAT-Piercing ). Der Teredo-Client und der native IPv6-Host nutzen das Relay anschließend für die Kommunikation, solange sie diese benötigen. Diese Architektur bedeutet, dass weder der Teredo-Server noch der Client die IPv4-Adresse eines Teredo-Relays kennen müssen. Sie finden automatisch eine geeignete Adresse über die globale IPv6- Routingtabelle , da alle Teredo-Relays das Netzwerk 2001::/32 ankündigen.

Am 30. März 2006 war der italienische Internetdienstanbieter ITGate ^{[ 5 ]} der erste autonome Dienst, der eine Route zum IPv6-Netz 2001::/32 ankündigte, um die volle Nutzbarkeit von RFC-4380-konformen Teredo-Implementierungen zu gewährleisten. Seit dem 16. Februar 2007 ist diese Route nicht mehr funktionsfähig.

In Q1 2009, IPv6 backbone Hurricane Electric enabled 14 Teredo relays^[6] 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.

Officially, this mechanism was created for Microsoft Windows XP and onwards PCs to provide IPv6 connectivity to IPv4 clients by connecting to ipv6.microsoft.com and works in conjunction with IP Helper service and Teredo Tunneling Adapter Interface driver. The service also opens a UPNP port on the router for relaying.

Teredo is not compatible with all NAT devices. Using the terminology of RFC 3489, it supports full cone, restricted, and port-restricted NAT devices, but does not support symmetric NATs. The Shipworm specification^[7] original that led to the final Teredo protocol also supported symmetric NATs, but dropped that due to security concerns.

People at the National Chiao Tung University in Taiwan later proposed SymTeredo,^[8] which enhanced the original Teredo protocol to support symmetric NATs, and the Microsoft and Miredo implementations implement certain unspecified non-standard extensions to improve support for symmetric NATs. However, connectivity between a Teredo client behind a symmetric NAT, and a Teredo client behind a port-restricted or symmetric NAT remains seemingly impossible.

Teredo geht davon aus, dass beim Austausch gekapselter IPv6-Pakete zwischen zwei Clients die verwendeten externen UDP-Portnummern mit denen übereinstimmen, die für die Kontaktaufnahme mit dem Teredo-Server (und den Aufbau der Teredo-IPv6-Adresse) verwendet wurden. Ohne diese Annahme wäre eine direkte Kommunikation zwischen den Clients nicht möglich, und ein ressourcenintensiver Relay-Server müsste für das Triangle-Routing eingesetzt werden . Eine Teredo-Implementierung versucht beim Start, den NAT-Typ zu erkennen und verweigert den Betrieb, wenn ein symmetrisches NAT vorliegt. (Diese Einschränkung lässt sich unter Umständen durch manuelle Konfiguration einer Portweiterleitungsregel auf dem NAT-Gerät umgehen, wofür Administratorrechte erforderlich sind.)

Teredo kann pro Tunnelendpunkt nur eine einzige IPv6-Adresse bereitstellen. Daher ist es – anders als bei 6to4 und einigen IPv6-Punkt-zu-Punkt-Tunneln – nicht möglich, mehrere Hosts über einen einzigen Teredo-Tunnel zu verbinden. Die allen Teredo-Clients zur Verfügung stehende Bandbreite zum IPv6-Internet ist durch die Verfügbarkeit von Teredo-Relays begrenzt, die sich in dieser Hinsicht nicht von 6to4-Relays unterscheiden.

6to4 benötigt eine öffentliche IPv4-Adresse, stellt aber für jeden Tunnelendpunkt ein großes 48-Bit-IPv6-Präfix bereit und hat einen geringeren Kapselungsaufwand . Punkt -zu-Punkt -Tunnel sind zuverlässiger und besser nachvollziehbar als Teredo und bieten typischerweise permanente IPv6-Adressen, die nicht von der IPv4-Adresse des Tunnelendpunkts abhängen. Einige Punkt-zu-Punkt- Tunnelbroker unterstützen auch UDP-Kapselung zur Überwindung von NATs (beispielsweise das AYIYA -Protokoll). Andererseits erfordern Punkt-zu-Punkt-Tunnel normalerweise eine Registrierung. Automatisierte Tools (z. B. AICCU ) erleichtern die Nutzung von Punkt-zu-Punkt-Tunneln.

Teredo vergrößert die Angriffsfläche , indem es Netzwerk-Hosts hinter NAT-Geräten global routbare IPv6-Adressen zuweist, die andernfalls aus dem Internet nicht erreichbar wären. Dadurch setzt Teredo potenziell jede IPv6-fähige Anwendung mit einem offenen Port nach außen aus. Die Tunnelkapselung von Teredo kann zudem dazu führen, dass der Inhalt des IPv6-Datenverkehrs für Paketinspektionssoftware unsichtbar wird, was die Verbreitung von Schadsoftware erleichtert. ^{[ 9 ]} Schließlich macht Teredo den IPv6-Stack und die Tunneling-Software angreifbar, falls diese Schwachstellen aufweisen, die aus der Ferne ausgenutzt werden können.

Um die Angriffsfläche zu verringern, verfügt der Microsoft IPv6-Stack über eine Socket- Option namens „Schutzstufe“. Diese ermöglicht es Anwendungen, festzulegen, von welchen Quellen sie IPv6-Datenverkehr akzeptieren möchten: vom Teredo-Tunnel, von beliebigen anderen Quellen (Standardeinstellung) oder nur vom lokalen Intranet .

Das Teredo-Protokoll kapselt zudem detaillierte Informationen über den Endpunkt des Tunnels in seine Datenpakete. Diese Informationen können potenziellen Angreifern helfen, indem sie die Durchführbarkeit eines Angriffs erhöhen und/oder den erforderlichen Aufwand verringern. ^{[ 10 ]}

Damit ein Teredo-Pseudo-Tunnel ordnungsgemäß funktioniert, müssen ausgehende UDP-Pakete an Port 3544 ungefiltert sein. Auch Antworten auf diese Pakete (sog. „angeforderter Datenverkehr“) müssen ungefiltert sein. Dies entspricht der typischen Konfiguration eines NAT-Routers und seiner zustandsbehafteten Firewall . Die Teredo-Tunneling-Software meldet einen schwerwiegenden Fehler und beendet sich, wenn ausgehender IPv4-UDP-Datenverkehr blockiert wird.

Im Jahr 2010 wurden neue Methoden zur Erzeugung von Denial-of-Service-Angriffen über Routing-Schleifen mithilfe von Teredo-Tunneln entdeckt. Diese sind relativ leicht zu verhindern. ^{[ 11 ]}

Microsoft Windows deaktiviert Teredo ab Version 10, Version 1803, standardmäßig. Bei Bedarf kann diese Übergangstechnologie über einen CLI- Befehl oder eine Gruppenrichtlinie aktiviert werden . ^{[ 12 ]}

Derzeit sind mehrere Implementierungen von Teredo verfügbar:

• Windows XP SP2 beinhaltet ein client- und hostspezifisches Relay (auch im Advanced Networking Pack für Service Pack 1 enthalten).
• Windows Server 2003 verfügt über einen Relay- und Serverdienst, der im Rahmen des Microsoft Beta-Programms bereitgestellt wird.
• Windows Vista und Windows 7 bieten integrierte Unterstützung für Teredo mit einer nicht näher spezifizierten Erweiterung für symmetrisches NAT-Traversal. Sind jedoch nur eine Link-Local- und eine Teredo-Adresse vorhanden, versuchen diese Betriebssysteme nicht, IPv6-DNS-AAAA-Einträge aufzulösen, wenn ein DNS-A-Eintrag existiert. In diesem Fall verwenden sie IPv4. Daher nutzen typischerweise nur IPv6-URLs mit wörtlicher Schreibweise Teredo. ^{[ 13 ]} Dieses Verhalten kann in der Registry angepasst werden .
• Windows 10 Version 1803 und höher deaktivieren Teredo standardmäßig. Bei Bedarf kann diese Übergangstechnologie über einen CLI- Befehl oder eine Gruppenrichtlinie aktiviert werden . ^{[ 12 ]}
• Miredo ist ein Client, Relay und Server für Linux , *BSD und Mac OS X.
• ng_teredo ist ein Relay- und Server-System auf Basis von netgraph für FreeBSD von der LIP6 University und 6WIND. ^{[ 14 ]}
• NICI-Teredo ist ein Relay für den Linux-Kernel und ein Teredo-Benutzerserver, der an der National Chiao Tung University entwickelt wurde. ^{[ 15 ]}

Der ursprüngliche Spitzname des Teredo-Tunneling-Protokolls war „Shipworm“ . Die Idee war, dass das Protokoll NAT-Geräte durchdringen würde, ähnlich wie der Schiffsbohrwurm (eine Art holzbohrende Muschel) Tunnel durch Holz bohrt. Schiffsbohrwürmer haben zum Untergang vieler Holzrümpfe beigetragen. Christian Huitema merkte im ursprünglichen Entwurf an, dass der Schiffsbohrwurm „nur in relativ sauberem und unbelastetem Wasser überlebt; seine jüngste Rückkehr in mehrere nordamerikanische Häfen ist ein Beweis für deren wiederhergestellte Sauberkeit. Der Shipworm-Dienst sollte wiederum zu einer wiederhergestellten Transparenz des Internets beitragen . “ ^{[ 16 ]}

Um Verwechslungen mit Computerwürmern zu vermeiden , ^{[ 17 ]} änderte Huitema später den Namen des Protokolls von Shipworm in Teredo , nach dem Gattungsnamen des Schiffsbohrwurms Teredo navalis . ^{[ 17 ]}

• Teredo-Übersicht auf Microsoft TechNet
• Aktuelle Anycast-Teredo-BGP-Routen
• Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) . RFC 4380, C. Huitema. Februar 2006.
• JavaScript-Teredo-IP-Adressrechner