Seite 4: Wie funktioniert es?

Inhaltsverzeichnis

Letzte Ausfahrt

Microsoft bezeichnet seine Tunneltechnik selbst als letzten Ausweg: Sie soll nur dort zum Einsatz kommen, wo andere IPv6-Verbindungswege verschlossen sind. Teredo-Verbindungen verursachen im Netzwerk viel Aufwand, sind vergleichsweise uneffektiv und nicht besonders stabil. Der hohe Aufwand kommt besonders dadurch zustande, das Teredo Tunnel-Verbindungen durch NAT-Router bohrt, deren Eigenheiten es beim Tunnelaufbau ermittelt.

Im Allgemeinen unterscheidet man die vier NAT-Varianten Full Cone, Restricted Cone, Port Restricted Cone und Symmetric, die sich allerdings miteinander mischen lassen. Teredo kann mit allen NAT-Arten umgehen. Teredo-Clients unter Windows XP verstehen sich jedoch nicht mit jedem symmetrischen NAT. Für neuere Windows-Versionen steht eine Teredo-Erweiterung bereit, die dieses Problem für viele symmetrische NAT-Router beseitigt. Seit Version 1.1.0 beherrscht die Open-Source-Variante Miredo grundsätzlich diese NAT-Technik.

Teredo nutzt eine eigenes Adressformat: Die ersten 64 Bit einer Teredo-Adresse enthalten den Präfix 2001:0 und die hexadezimale Form der IPv4-Adresse der Teredo-Server. Es folgt ein 16-Bit-Block für Flags, dessen erste vier Bit den NAT-Typ kennzeichnen (Cone-Flag) und der eine 12-Bit lange Zufallszahl enthält, die zur Verbindungssicherung dient. In den folgenden 16 Bit steht die externe Port-Nummer des NAT-Routers. Die letzten 32 Bit enthalten die externe Adresse des NAT-Routers. Damit ein Router den Port und die Routeradresse nicht versehentlich umschreibt, invertiert Teredo die Angaben zum Router-Port und zur Router-Adresse per XOR-Verfahren.

2001:0:	d5c7:a2d6:	2c29:	1b81:	f5f5:213b
Teredo-Präfix	IPv4-Adresse des Teredo-Servers	Flags (NAT-Typ)	Externer Port	Externe IPv4-Adresse (des Routers)

Das Protokoll baut den IPv6-Tunnel über ein mehrstufiges Verfahren auf: Der Client kontaktiert im ersten Schritt über den UDP-Port 3544 einen Rechner im IPv4-Internet, den Teredo-Server. Die Adresse des Teredo-Servers ist beim Windows-Client mit teredo.ipv6.microsoft.com vorbelegt. Mittels Netsh lässt sie sich jedoch anpassen:

netsh interface ipv6 set teredo client teredo.example.com

Dieser Befehl setzt noch weitere Teredo-Parameter, eine Liste gibt das Kommando netsh interface ipv6 set teredo help aus.

Beim ersten Aufruf versucht Teredo herauszufinden, welchen NAT-Typ das lokale Netz nutzt, wie die externe Adresse des Routers lautet und welchen Port es für den Transport der eigentlichen IPv6-Daten nutzen kann. Dazu sendet der Client eine Router-Solication-Nachricht (RS), deren Cone-Flag besetzt ist. Der Teredo-Server antwortet über eine zweite IPv4-Adresse mit einer Router-Advertisment-Nachricht. Erhält der Client diese Nachricht, arbeitet der Teredo-Client in einem LAN, das per Cone-NAT mit dem Internet verbunden ist. Kommt nichts zurück, sendet der Client ein zweite RS-Nachricht ohne gesetztes Cone-Flag, die der Server von seiner primären, vom Client als Zieladresse benutzten IP-Adresse beantwortet. Abschließend überprüfen Client und Server, ob das LAN des Clients symmetriches NAT nutzt.

Haben Client und Server diese Parameter ermittelt, sendet der Client in regelmäßigen Abständen Pakete an den Server, sodass der NAT-Router die Einträge in seiner NAT-Tabelle nicht löscht.

Will der Teredo-Client eine IPv6-Rechner ansprechen, erfragt er über den Server für jede IPv6-Gegenstelle einen Relay, der den eigentlichen IPv-Verkehr an den Client transportiert. Die jeweils passende Relay-Adresse ermittelt der Client über ICMPv6-Anfragen: Er schickt eine ICMP-Echo-Nachricht an die IPv6-Gegenstelle, die er in UDP-Pakete verpackt und an den Teredo-Server sendet. Der Server packt die Nachricht aus und leitet sie per IPv6 an die Gegenstelle weiter. Der IPv6-Zielrechner antwortet mit einer Echo-Reply-Nachricht, die durch das IPv6-Routing zum nächstliegenden Relay gelangt, denn dieses zeigt sich gegenüber seinen Nachbarn für das Routing zu Teredo-Adressen zuständig. Der Relay verpackt die IPv6-Nachricht in IPv4-UDP-Paket und sendet sie dank der in der Teredo-Adresse gespeichertern Client-Adresse dem Client direkt zu.

Benutzt der Router des Client-LANs eine Port Restricted NAT, ist an dieser Stelle ein zusätzlicher Schritt (Bubble-to-open-Procedure) notwendig: Der NAT-Router kennt die Adresse des Relay bislang nicht. Ihm fehlt ein entsprechender Eintrag in seiner NAT-Tabelle und somit blockiert er dessen Netzwerkpakete. Der Relay sendet daher ein IPv6-Paket über den Teredo-Server an den Client, der nun Kontakt mit dem Relay aufnimmt und damit einen Eintrag in der NAT-Tabelle des Routers erzeugt. Anschließend läuft sämtlicher IPv6-Verkehr für dieses Ziel über das ermittelte Relay.