Ja, das ist mit dem Teredo-Protokoll möglich. Es erfordert jedoch geänderten Code sowohl auf dem Teredo-Client als auch auf dem Teredo-Server.
Um zu erklären, warum es nach der Änderung von Client und Server immer noch als dasselbe Protokoll angesehen werden kann, muss ich zunächst erklären, was die anderen an der Kommunikation beteiligten Komponenten sind.
Teredo-Grundlagen
Die vier kritischen Netzwerkknoten in einer Kommunikation, die das Teredo-Protokoll verwendet, sind:
- Teredo-Client
- Teredo-Server (vom Client ausgewählt)
- Teredo-Relay (vom nativen IPv6-Knoten ausgewählt)
- Nativer IPv6-Knoten
Letztendlich ist es der Teredo-Client und der native IPv6-Knoten, die IPv6-Pakete austauschen möchten. Die Teredo-Server und Teredo-Relays sind vorhanden, um diesen Datenverkehr zu erleichtern.
Der Teredo-Server ist nur am ersten Verbindungsaufbau beteiligt. Sobald die Verbindung hergestellt ist, wird der Datenverkehr zwischen dem Teredo-Client und dem nativen IPv6-Knoten durch das Relay geleitet, ohne dass der Teredo-Server Datenverkehr empfängt.
Da der Client keinen Einfluss auf die Wahl des Teredo-Relais hat, funktioniert jede Lösung, die Änderungen am Relais erfordern würde, nicht. Zum Glück ist das nicht erforderlich. Die Verbindung zwischen Client und Relay, an die der Hauptteil des Datenverkehrs gesendet wird, ist weiterhin vollständig Teredo-Standardverkehr.
Da Client und Relay weiterhin unter Verwendung des Standard-Teredo kommunizieren und der Client noch eine IPv6-Adresse im 2001::/32Präfix hat, gilt dies als Teredo.
Änderungen nötig
12 der Bits in der Teredo-Adresse werden vom Teredo-Client zufällig ausgewählt. Auf der Clientseite ist eine Änderung erforderlich, damit diese nicht zufällig sind.
48 der Bits in der Teredo-Adresse sind die IPv4-Adresse und die UDP-Portnummer des Teredo-Clients, wie sie vom Teredo-Server angezeigt werden.
Hier ist es sehr wichtig, dass diese 48 Bits die Portadresse sind, die der Server sieht. Aufgrund von NAT denken Client und Relay möglicherweise, dass der UDP-Port eine völlig andere Adresse hat. Welche IPv4-Adresse und Portnummer Client und Relay sehen, hat jedoch keinen Einfluss auf die endgültige IPv6-Adresse.
Normalerweise befindet sich das einzige betroffene NAT in der Nähe des Teredo-Clients. Wenn Sie jedoch die endgültige IPv6-Adresse beeinflussen möchten, kann ein NAT auf demselben Computer wie der Teredo-Server abgelegt werden. Es ist sogar möglich, NAT direkt in den Teredo-Server einzubauen, wenn Sie dazu neigen.
Gibt es eine Implementierung davon?
Wahrscheinlich nicht.
Ich habe zuvor den größten Teil eines Teredo-Servers implementiert . Der Client kann jedoch nur die IPv4-Adresse und nicht die UDP-Portnummer auswählen. Ich brauchte die UDP-Portnummer, um Clients zu unterscheiden.
Ein Teredo-Server mit Unterstützung für das Festhalten der IPv4-Adresse und des UDP-Ports für einen bestimmten Benutzer erfordert eine Möglichkeit, den Benutzer zu erkennen. Es gibt Felder im Protokoll, die möglicherweise dazu verwendet werden können. Ich kenne jedoch keine Implementierung mit Unterstützung für die Identifizierung von Teredo-Clients für Teredo-Server.
Darüber hinaus leidet Teredo an einem erheblichen Zuverlässigkeitsproblem. Dieses Zuverlässigkeitsproblem bezieht sich auf den Teil des Teredo-Protokolls, der von den hier beschriebenen Änderungen nicht berührt wird.
Das Problem mit Teredo
Das Problem ist, wie der native IPv6-Knoten das zu verwendende Teredo-Relay wählt. Idealerweise konfiguriert der Administrator des Netzwerks, auf dem sich der native IPv6-Knoten befindet, ein Teredo-Relay für dieses Netzwerk (und befindet sich außerhalb des NAT, wenn NAT für IPv4 verwendet wird).
Viele Administratoren entscheiden sich jedoch nicht für die Bereitstellung eines Teredo-Relays. Normalerweise wird argumentiert, dass Teredo so unzuverlässig ist, dass sie es nicht unterstützen müssen (ohne zu ahnen, dass diese Überlegung Teredo unzuverlässig macht, eine sich selbst erfüllende Prophezeiung).
Stattdessen wird der Datenverkehr vom nativen IPv6-Knoten über die Standardroute an den Upstream-Provider gesendet, der ihn wiederum an seinen Upstream-Provider senden kann und der Datenverkehr möglicherweise auf einem öffentlichen Relay eines Drittanbieters auf einem AS landet beschlossen zu verkünden 2001::/32.
Die Verwendung eines Relays eines Drittanbieters bedeutet einen längeren Netzwerkpfad, was wiederum eine erhöhte Latenz bedeutet. Dies bedeutet auch, dass es keine SLA gibt und das Teredo-Relais möglicherweise nicht über ausreichende Kapazität für den an ihn gesendeten Datenverkehr verfügt.
In den meisten Fällen, in denen eine statische IP-Adresse gewünscht wird, ist auch eine gewisse Zuverlässigkeit erwünscht. Da Sie selten alle Remote-Knoten steuern, mit denen Sie kommunizieren, haben Sie auch keine Kontrolle darüber, welche Teredo-Relais verwendet werden.
Dies macht Teredo mit statischer IP-Adresse zu einem Nischenprodukt für diejenigen, die bereit sind, einen modifizierten Teredo-Client zu installieren, um eine statische IP-Adresse zu erhalten, für die keine Zuverlässigkeit garantiert wird.