IPv6/Windows: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „__KEIN_INHALTSVERZEICHNIS__“ durch „“
 
(10 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''IPv6 unter Windows''' - Grundlagen
'''IPv6 unter Windows'''
 
{| class="wikitable options"
== IPv6-Grundkonfiguration für Windows ==
|-
[[IPv6/Windows/Grundkonfiguration]]
! Option !! Beschreibung
 
|-
== IPv6 im Windows-Netz ==
| [[IPv6/Windows/Grundkonfiguration|Grundkonfiguration]] || IPv6-Grundkonfiguration für Windows
[[IPv6/WindowsIPv6ImWindowsNetz]]
|-
 
| [[IPv6/WindowsIPv6ImWindowsNetz|IPv6 im Windows-Netz]] || IPv6 im Windows-Netz
== IPv6 unter Windows ==
|-
[[IPv6/Windows/IPv6 unter Windows]]
| [[IPv6/Windows/IPv6 unter Windows|IPv6 unter Windows]] || IPv6 unter Windows
 
|-
== DHCP mit IPv6 ==
| [[IPv6/Windows/DHCP mit IPv6|DHCP mit IPv6]] || DHCP mit IPv6
[[IPv6/Windows/DHCP mit IPv6]]
|-
 
| [[IPv6/Windows/IPv6Support|IPv6-Support]] || IPv6-Support
[[IPv6/Windows/IPv6Support]]
|-
 
| [[IPv6/Windows/IPv6 Subnetz|IPv6 Subnetz]] || IPv6 Subnetz – Was ist das Richtige für mich?
== IPv6 Subnetz – Was ist das Richtige für mich? ==
|-
Nachdem die ganze öffentliche Vergabe von IPv6 Adressen noch sehr schleppend ist, lohnt der Aufbau vorher eigentlich nicht. Die Telekom will bis Ende 2011 auch Endanwendern IPv6 anbieten. Wer aber schon gewappnet sein will, wenn's dann doch soweit ist, kann sich schon mal mit dem Thema vertraut machen.
| [[IPv6/Windows/Allgemein|Allgemein]] || IPv6 Allgemein
 
|-
Es gibt einen Standard-IPv6-Bereich, der vergleichbar mit dem private Class A / B / C Netzen von IPv4 ist, eine sog. ''Site local address''. Übrigens, die ''Link local address'' (fe80::/64) ist mit der 169.254.0.0/16 bei IPv4 vergleichbar. Wenn man also noch keine offizielle, von der IETF oder dem ISP zugewiesene IPv6 hat, sollte auch nicht auf die Idee kommen irgendeine zu verwenden. Das macht früher oder später nur Probleme und man muss erneut umstellen. Folgende Site local Adresse ist frei verfügbar:
| [[IPv6/Windows/IPv6-Labor|IPv6-Labor]] || IPv6-Labor
 
|-
'''Site local: fec0:: '''
| [[IPv6/Windows/Teredo|Teredo]] || Microsofts Tunnelmechanismus Teredo
 
|-
'''Subnetz prefix length: 64 '''
| [[IPv6/Windows/Router Advertisements|Router Advertisements]] || IPv6 Router Advertisements on Windows
 
|-
Gleiches Netz, andere Schreibweise:
| [[IPv6/Windows/Netsh-Befehle|Netsh-Befehle]] || Netsh-Befehle für IPv6
 
|}
'''Address prefix:''' '''fec0::/64 '''
 
Man könnte auch ein anderes Subnetz innerhalb von fec0 verwenden, allerdings bevorzuge ich kurze Schreibweisen. Beispiel für ein Subnetz wäre: fec0:0:0:1::
 
Die Übersicht über alle Adressen gibt's hier: [http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml]
 
=== Testumgebung ===
* Server A:
** Windows 2008 R2
** AD, DNS
** IPv6: fec0::3
* Server B:
** Windows 2008 R2
** DHCP
** IPv6: fec0::2
* Client:
** Windows 7
** IPv6: DHCP (z.B. fec0::aaaa)
 
In dieser Umgebung gibt es keinen IPv6 fähigen Router und damit auch kein Gerät was per Router Discovery gefunden wird.
 
=== Statische IPv6 vergeben ===
Nachdem IPv6 mittlerweile standardmäßig aktiv ist, muss man in den Protokolleigenschaften lediglich eine statische IP-Adresse eintragen, hier am Server B:
 
[[Image:Bild8.png|top|alt="image"]]
 
Server A erhält die IP fec0::3.     
 
Über '''ping -6 fec0::3''' kann man die IPv6 Konnektivität von A nach B überprüfen (wenn ich den Parameter '''-6''' nicht angebe, versucht Windows es zuerst über IPv6. Mit dem Parameter erzwingt man das Ganze):
 
[[Image:Bild9.png|top|alt="image"]]
 
=== Konfiguration DHCP-Server ===
Während der Installation der DHCP-Server Rolle, wird man gefragt, ob man den DHCP im Stateless oder Stateful Modus betreiben möchte, für diesen Verwendungszweck ist Stateful die richtige Wahl.
 
DHCP-Bereich: fec0:: /64
 
Ausnahmen: * fec0::ffff bis fec0::ffff:ffff:ffff:ffff (ich möchte dass meine Clients möglichst kurze Adressen bekommen, und 65.000 IP's reichen mir)
* fec0::1 bis fec0::20 (meine statischen IPv6 Adressen sind im Bereich 1-20, deshalb soll dieser nicht per DHCP vergeben werden)
 
Server Options: * 00023 DNS Recursive Name Server IPv6 Addresss: fec0::3
 
Wenn ich jetzt am Client meine IPv6 Adresse per '''ipconfig /renew6 '''erneuere, bekomme ich z.B. fec0::aaaa
 
Starte ich einen ping vom Client zum Server ('''ping -6 fec0::3''') kann es passieren, dass ich nur '''PING: transmit failed. General failure.''' Bekomme. Als nächstes sollte man den ping über link local Adresse (fe80::/64) versuchen, das sollte klappen. In diesem Fall hilft der nächste Schritt.
 
=== Zusätzliche Konfiguration am DHCP-Server ===
An dieser Stelle scheitert man ganz gerne. IPv6 ist auf das sog. Router Advertisement angewiesen, damit ein Routing im Netzwerk möglich ist. Nun steht uns aber kein IPv6 fähiger Router zur Verfügung, d.h. der DHCP-Server soll diese Aufgabe übernehmen. Dazu sind ein paar Kniffe über netsh notwendig. Ohne das Router Advertisement bekommt der Client auch keine Route ins eigene Netz zugewiesen. Über den folgenden Befehl kann man sich die Routen anzeigen lassen:
 
'''netsh int ipv6 show route '''
 
Hier fehlt fec0:: - unser neues Netz.
 
Damit es als Route hinzugefügt wird, muss man am DHCP-Server folgendes konfigurieren: # Auf der Netzwerkkarte Advertise=enabled setzen
# Für die entsprechende Route, also fec0::, die Eigenschaft publish=enabled setzen
 
Schritt 1:
 
Man muss die ID der betroffenen Netzwerkkarte herausfinden: '''netsh int ipv6 show int'''
 
Anschließend muss Advertise=enabled gesetzt werden: '''netsh int ipv6 set int <ID> advertise=enabled'''&nbsp;&nbsp; // optional noch: rou=en (das sollte schon enabled sein)
 
Schritt 2:
 
Anschließend die Route hinzufügen: '''netsh int ipv6 add route fec0::/64 publish=enabled '''
 
Falls es die schon gibt, kann man die Eigenschaft publish wie folgt ändern: '''netsh int ipv6 set route fec0::/64 publish=enabled '''
 
Update, mit einem Service Pack hat sich scheinbar der Syntax geändert, z.B.: '''netsh int ipv6 set route fec0::/64 "LAN" publish=yes'''
 
[[Image:Bild10.png|top|alt="image"]]
 
Anschließend sollte ein ping vom Client zu Server A & B möglich sein. Alle weiteren IPv6 fähigen Clients können dann ohne zusätzliche Konfiguration über IPv6 kommunizieren.
 
=== Troubleshooting Tools ===
Wertvolle Helfer auf der Kommandozeile, die speziell auf IPv6 losgehen: * ping –6 <hostname>
* tracert –6 <hostname>
* ipconfig /release6
* ipconfig /renew6
* netsh int ipv6 show int
* netsh int ipv6 show int <ID>
* netsh int ipv6 show route
 
=== Quelle ===
http://www.hobmaier.net/2012/12/stateful-ipv6-autoconfiguration-mit.html
 
== IPv6 Allgemein ==
[[IPv6/Windows/Allgemein]]
 
== IPv6-Labor / Pilot ==
[[IPv6/Windows/IPv6-Labor]]
 
== Microsofts Tunnelmechanismus Teredo ==
'''Tunnelbroker oder den Provider wechseln? Ein IPv6-Zugang einzurichten, erscheint schwierig. Aktuelle Betriebssystem haben jedoch die Tunneltechnik Teredo an Bord, die sie ins IPv6-Netz bringt und die nur noch in Gang geklickt werden muss.'''
 
IPv6 nutzt Adressen mit 128&nbsp;Bit, räumt durch seinen enormen Vorrat mit der Knappheit an Adressen bei IPv4 auf und entsorgt lästige IPv4-Netzwerktricks wie Network Address Translation [1].
 
Mit IPv6 [2] müsste niemand mehr den DSL-Router aufwendig eine Portweiterleitung beibringen, wenn LAN-Rechner Dateien ins Internet stellen sollen oder man auf Vaters Rechner Treiber-Probleme beheben muss. Doch der Traum von der globalen Erreichbarkeit endet jäh am eigenen DSL-Anschluss, der hierzulande in den meisten Fällen ausschließlich IPv4 spricht und zumeist bei jeder Einwahl die Adresse wechselt.
 
Die IPv6-freie Zone zwischen dem eigenen Rechner und Servern im Internet lässt sich jedoch mit Hilfe von Netzwerktunneln überbrücken. Vista und Windows XP seit Servicepack&nbsp;1 haben einen solchen Tunnelmechanismus an Bord, den Microsoft den Namen des Schiffsbohrwurms Teredo navalis [3] verpasste und der im RFC 4380 [4] veröffentlicht wurde.
 
Teredo [5] nimmt dem Benutzer die Konfiguration weitgehend aus der Hand, in vielen Fällen funktioniert es ohne weitere Eingriffe. Es benötigt lediglich eine per IPv4 erreichbare Server-Adresse – den Rest der Arbeit übernimmt die Software. Andere Tunnelverfahren wie 6to4 funktionieren nur mit einer global-gültigen IPv4-Adresse und arbeiten daher nur im LAN-Router selbst, der per DSL direkt mit dem Internet verbunden ist. Einige Hersteller wie Apple und AVM haben diese Technik bereits in ihre Geräte eingebaut oder bieten diese Funktion über ein Firmware-Update [6] an.
 
Wie auch andere IPv6-Tunnelverfahren verpackt Teredo die IPv6-Daten in UDP [7]-Pakete und sendet sie per IPv4 an einen Server, der sowohl im IPv4- als auch im IPv6-Netz steht. Teredo tunnelt IPv6-Pakete jedoch aus einem per Network Address Translation (NAT) geschützten IPv4-Netz heraus, was sonst nur zusätzliche Client-Software wie Aiccu [8] oder Hexagos Gateway6 [9] beherrschen.
 
Trotz oder gar wegen aller Automatiken tauchen bei der Einrichtung und beim Betrieb von Teredo einige Probleme auf, die dem angehenden IPv6-Surfer im Wege stehen können. So argwöhnt mancher Windows-Benutzer Böses, wenn er in der Eingabeaufforderung den Teredo-Adapter sieht.
 
Derartige Netzwerktunnel setzen sich zudem über die Sicherheitsvorgaben des Netzwerkadministrators hinweg, da sie Daten am NAT-Router und der IPv4-Firewall [10] vorbei ins IPv4-Netzwerk schleusen können. IPv6 hebelt damit das Konzept des per NAT abgeschotteten lokalen Netze aus: IPv6-Rechner sind immer direkt erreichbar, wenn nicht die Firewall den Verbindungsaufbau blockiert.
 
Als IPv6-Tunnelmechanismus soll Teredo den Übergang von IPv4 auf das Nachfolgeprotokoll IPv6 vereinfachen. Ziel des Protokolls ist es ausdrücklich, Rechnern in lokalen (IPv4-)Netzen eine global gültige IPv6-Adresse zu verpassen.
 
=== Einrichtung unter Windows XP ===
Auf einen Windows&nbsp;XP seit Servicepack&nbsp;2 benötigt Teredo lediglich den IPv6-Stack, der sich in den Netzwerkeinstellungen über die Eigenschaften der Netzwerkkarte oder als Administrator mit dem Netsh-Kommando <tt>netsh interface ipv6 install</tt> installieren lässt.
 
Anschließend sollte der Befehl <tt>netsh interface ipv6 show addresses</tt> an der Netzwerkkarte link-lokale IPv6-Adresse anzeigen, die sich am Präfix <tt>fe80::</tt> erkennen lässt.
 
[[Image:Bild51.png]]
 
Der Teredo-Client hat eine Verbindung aufgebaut und kann IPv6-Adressen aufrufen. Anschließend zeigt das Kommando <tt>netsh interface ipv6 show teredo</tt> unter XP (und Vista) den Teredo-Status an: Meldet der Befehl beim Punkt "Status:" den Wert "qualified", steht der Teredo-Tunnel und der Heise-IPv6-Versuchsserver www.six.heise.de sollte auf ICMPv6-Pakete antworten, die das Kommando <tt>ping -6 www.six.heise.de</tt> anfordert. Endet das Ping-Kommando mit Fehlermeldungen, kann es sein, dass der Client den Tunnel noch nicht aufgebaut hat.
 
Rufen Sie das Kommando einfach ein zweites Mal auf, denn das unten beschriebene Auffinden des Teredo-Relays dauert oft etwas länger. Sollte Teredo ein verwaltetes Netzwerk erkennen und sich daher deaktivieren, hilft in einigen Netzen der Teredo-Enterpriseclient, der sich über Netsh anschalten lässt:
 
netsh interface ipv6 set teredo enterpriseclient
 
Wenn auch diese Einstellung nicht hilft, steht der Rechner in einem Netz, das wahrschienlich für Teredo nicht taugt. Das Verfahren versagt nämlich in LANs, deren Routern symmetrisches NAT einsetzen oder von einer Firewall geschützt werden, die UDP-Verkehr blockiert.
 
Auskunft über den Status oder den aktiven Tunnel liefert wiederum der Befehl <tt>netsh interface ipv6 show teredo</tt>.
 
Teredo-Parameter
Typ : client
Servername : default
Clientaktual.-intervall : default
Clientport : default
Status : dormant
Typ : Teredo client
Netzwerk : managed
NAT : none (global connectivity)
 
Diese Ausgabe zeigt eine "schlafenden" Teredo-Client, der mit hoher Wahrscheinlich keine Tunnel aufbauen kann, denn er erkennt den NAT-Typ nicht und deklariert das LAN als verwaltetes Netz.
 
Steht jedoch der Teredo-Tunnel, liefern die Kommandos <tt>ipconfig /all</tt> oder <tt>netsh interface ipv6 show address</tt> die global gültige Adresse des Teredo-Tunneladapters. Diese Adresse startet immer mit ''2001:0:'', die mit ''fe80::'' beginnende (link-lokale) Adresse des Adapters gilt nur im aktuellen Netzwerksegment.
 
Windows XP benötigt keine weiteren Einstellungen, wenn der Rechner über Programme wie Firefox&nbsp;3, Internet Explorer&nbsp;7 oder den SSH [11]-Client Putty [12] Internet-Adressen per IPv6 abruft.
 
=== Vista Spezial ===
Microsoft aktiviert Teredo in seiner aktuellen Windows-Version Vista, schaltet es aber automatisch ab, wenn das Betriebssystem merkt, dass das lokale Netz IPv6 spricht, die Vista-Firewall abgeschaltet ist oder das LAN verwaltet wird, was Teredo an einem Active Directory [13] bemerkt.
 
Besitzt der Vista-Rechner nur link-lokale oder Teredo-IPv6-Adressen [14] an seinen Netzwerkadaptern, erfragt das Betriebssystem die für IPv6 nötigen AAAA-Record nur dann, wenn ein Anwendungsprogramm wie ping sie ausdrücklich anfordert. So ermittelt unter Vista der Befehl <tt>ping -6 www.six.heise.de</tt> die korrekte IPv6-Adresse zum Heise-IPv6-Testserver, ein Aufruf der Website scheitert hingegen mit einer Fehlermeldung des DNS [15]-Resolvers.
 
Dieses Manko behebt eine IPv6-Adresse für die Netzwerkkarte, die mit der Zifferfolge ''2001:'' beginnt und den Präfix /48 besitzt. In unseren Versuchen funktionierten beispielsweise die Adressen aus dem für Dokumentationszwecke reservierten IPv6-Bereich [16] 2001:db8, die sich über die Eigenschaften der Netzwerkverbindung in der Systemsteuerung oder per Netsh setzen lassen.
 
netsh interface ipv6 set address "LAN-Verbindung" 2001:db8::1/48
 
Besitzt der Rechner mehrere Netzwerkkarten, müssen Sie eventuell die Zeichenfolge "LAN-Verbindung" anpassen: Der Aufruf von <tt>ipconfig /all</tt> oder <tt>route -6 print</tt> gibt unter Windows die Namen aller Netzwerkadapter aus.
 
Dabei zeigt es auch die Nummer des Adapters, die für den letzten Schritt ist – das Setzen einer Route. Hat das Teredo-Interface beispielsweise die Nummer&nbsp;9, setzt der Befehl
 
netsh interface ipv6 add route ::/0 9
 
die nötige Route. Weitere Details zum Routing und zu Teredo finden sich in dem Microsoft-Dokument IPv6 Transsition Technologies [17].
 
=== Teredo mit Linux, BSD und OS X ===
Dank der Veröffentlichung des Teredo-Protokolls im RFC 4380 [18] und der Arbeit des Linux-Kernelentwicklers Rémi Denis-Courmont steht mitterweile die quelloffene Teredo-Implementierung Miredo bereit, die unter Linux und BSD-Unixen läuft und sich als fertiges Paket beispielsweise in den Distributionen Debian, Opensuse und FreeBSD findet.
 
Für Mac OS&nbsp;X steht unter www.deepdarc.com/miredo-osx [19] ein fertiges Softwarepaket einer Miredo-Testversion bereit, die allerdings bereits gut zwei Jahre alt ist. In einem Subversion-Repository [20] finden sich die passenden Quelltexte.
 
[[Image:Bild24.png|top]]
 
Unter Linux verbindet das Paket Miredo den Rechner per Teredo-Tunnel mit dem IPv6-Internet Unter Debian oder Ubuntu startet Miredo nach der Installtion als Dienst. Der Eintrag "START_MIREDO" in der Datei /etc/default/miredo steuert, ob Miredo während des Systemstart den Tunnel aufbaut.
 
Details zum Verbindungsaufbau hinterlegt Miredo in der Datei /etc/miredo/miredo.conf:
 
<nowiki># Please refer to the miredo.conf(5) man page for details.</nowiki>
InterfaceName teredo
<nowiki># Pick a Teredo server:</nowiki>
<nowiki># ServerAddress teredo.ipv6.microsoft.com</nowiki>
ServerAddress teredo-debian.remlab.net
 
<tt>ServerAddress</tt> legt fest, welchen Teredo-Server der Client anfragen soll – im Beispiel den Teredo-Server des Miredo-Entwicklers. Wie auch der Microsoft-Teredo-Server verrichtet dieser ohne zusätzliche Anmeldung seine Dienste. Mit <tt>InterfaceName</tt> vergibt die Software den Namen für das Tunnel-Interface. Weitere Einstellungen benötigt der Tunnel nicht und auch die Namensauflösung funktioniert unter Linux klaglos.
 
=== 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 [21] 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&nbsp;XP verstehen sich jedoch nicht mit jedem symmetrischen NAT. Für neuere Windows-Versionen steht eine Teredo-Erweiterung [22] bereit, die dieses Problem für viele symmetrische NAT-Router beseitigt. Seit Version&nbsp;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 <tt>2001:0</tt> 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.
 
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 <tt>teredo.ipv6.microsoft.com</tt> 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 <tt>netsh interface ipv6 set teredo help</tt> aus.
 
[[Image:Bild26.png|top]]
 
Teredo nutzt für den Tunnelaufbau einen Internet-Server, der beim Ausmessen der Verbindung und des NAT-Routers hilft. Der eigentliche IPv6-Verkehr läuft anschließend über einen weiteren Rechner, das Teredo-Relay. 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.
 
[[Image:Bild38.png|top]]
 
Sitzt der Client in einem LAN mit Port-restricted NAT, muss der Router erst die Adresse des Relay lernen. 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 [23]-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.
 
=== Vor die Wand ===
Rechner mit aktiven Teredo-Tunneln sind wie alle IPv6-Rechner weltweit erreichbar. IPv6 benötigt schlicht keine Netwerk Address Translation, die im IPv4-Netzwerken eine gewissen Schutz für Angriffen bietet. Teredo umgeht jedoch diese vermeintliche Schutzfunktion [24].
 
Allerdings bringt beispielweise ein Windows XP von Hause aus keine IPv6-tauglichen Server-Dienste mit und ist von dieser Seite relativ sicher vor Angreifern. Vistas Firewall berücksichtigt auch den eingehenden IPv6-Verkehr, den sie in der Standardeinstellung blockiert.
 
Läuft die Vista-Firewall nicht, stoppt das Betriebssystem automatisch den Teredo-Tunnel. Betriebssysteme wie Linux benötigen hingegen einen zusätzlichen Paketfilter (ip6tables [25]), der Serverdienste auf dem Rechner schützt oder den Verkehr ins LAN kontrolliert.
 
Teredo lässt sich unter Windows zudem mit dem Befehl <tt>netsh interface ipv6 set teredo disable</tt> deaktivieren. Vistas grundsätzliche IPv6-Tauglichkeit bleibt dabei erhalten. Misstrauische Naturen können jedoch IPv6 und damit auch Teredo über die Eigenschaften der Netzwerkkarte vollständig deaktivieren.
 
=== Teredo sperren in der Fritz!Box ===
Teredo auf dem Router zu sperren, ist ganz einfach: Man blockiert den Datenverkehr auf UDP-Port 3544 und unterbindet so die Kommunikation mit dem Teredo-Server. Bei professionellen Firewalls ist das kein Problem, und auch die meisten Heim-Router bieten einen Paketfilter, in dem sich der UDP-Port blockieren lässt. Nicht so die Fritz!Box, die zwar einen Paketfilter enthält, dessen Konfiguration aber nicht über die Web-Oberfläche im Browser anbietet.
 
Daher ist etwas Fummelei per telnet [26] nötig. Wer sich mit Kommandozeilen und dem Editor vi [27] gar nicht auskennt, sollte unbedingt die Finger davon lassen. Um bei einem Fehler die funktionierende Konfiguration wiederherstellen zu können, sichert man sie zuerst über das Web-Interface in eine Datei (Einstellungen -> System -> Einstellungen sichern).
 
Dann schaltet man den Telnetserver frei, indem man auf einem an der Fritzbox angeschlossenen Telefon die magische Kombination #96*7* wählt. Die Box quittiert das bei Erfolg mit einem einsekündigen Dauertuten. Auf den freigeschalteten Server greift man dann mit dem Befehl <tt>telnet fritz.box</tt> zu. Unter Windows Vista muss dazu das telnet-Programm nachinstalliert [28] werden, die anderen Systeme bringen es ohne Weiteres mit.
 
Auf der Kommanozeile lädt der Befehl <tt>nvi /var/flash/ar7.cgf</tt> die zentrale Konfigurationsdatei in den vi-ähnlichen Editor. Dort sucht man nach dem Wort "dslifaces". In diesem Bereich gibt es nach ungefähr 30 Zeilen zwei Einträge "accesslist", einen unter "lowinput" und einen unter "highoutput". In beide fügt man als vorletzte Zeile <tt>"reject udp any any eq 3544",</tt> ein.
 
Das bedeutet, dass Pakete verworfen werden, und zwar UDP-Pakete von allen Adressen an alle Adressen sofern der Zeilport gleich 3544 ist. Der Sender erhält per ICMP eine Fehlermeldung. Nach dem Speichern der Datei gilt es nun, mit dem Befehl <tt>ar7cfgchanged</tt> die Konfiguration neu zu laden. Einzelne Meldungen wie "websrv: not found" oder "checkempty: No such file" sind dabei normal. Eine wesentlich längere Liste deutet jedoch auf einen Fehler beim Editieren der Datei hin.
 
Nun sollte ein Check des Teredo-Status auf einem PC im LAN (<tt>netsh interface ipv6 show teredo</tt>) zur Meldung
 
Status : offline
Fehler : Sekundäre Serveradresse ist nicht erreichbar
 
führen. Wenn alles geklappt hat, schaltet man den Telnet-Server mit der Wahl #96*8* wieder ab.
 
== IPv6 Router Advertisements on Windows ==
From my [http://rakhesh.com/windows/notes-on-ipv6/ previous post ]you know that IPv6 hosts can autoconfigure themselves if they get the network prefix from a router (or server running this service). Windows Server (and Clients) can send Router Advertisement messages without any additional software. This functionality is in-built and can be configure via the <tt>netsh</tt> command.
 
Here’s what I did on the Server Core 2012 which functions as the “router” for my test lab.# Visit [https://www.sixxs.net/tools/grh/ula/ https://www.sixxs.net/tools/grh/ula/ ]and get a ULA prefix for myself. This is a /48 block – meaning I have to fill in the remaining 16 bits of subnet ID to make this a /64 block. I can have 2^16 subnets. I got the fdcc:7c4e:3651::/48 prefix, I’ll just use subnet 1 for now, so my network prefix will be fdcc:7c4e:3651:'''1'''::'''/64'''.
# I assigned an IPv6 address “fdcc:7c4e:3651:1::254”, netmask 64, to the server.
# Next, I issued the following command on the server to enable router advertisements:<br/>netsh interface ipv6 set interface "Local Area Connection" advertise=enabled
 
netsh interface ipv6 set interface "Local Area Connection" advertise=enabledThis enables Router Advertisements. But this doesn’t advertise any prefixes.
 
Below is a Wireshark capture on that interface from a client:
 
[[Image:Bild52.png|top|alt="RA1"]]
 
Notice that Router Advertisement messages are being sent. The messages specify two options – MTU and the link-layer address of the router.
 
Here is the result of <tt>ipconfig</tt> for that interface on the client:
 
[[Image:Bild53.png|top|alt="ipconfig1"]]
 
The only IPv6 address is the link local address. No gateway is set either.
# To specify prefixes the publish, I issued the following command on the server:<br/>netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yes
 
netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesIn case that command gives an error – maybe you don’t have that route entry already – replace it with the following:
 
netsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesnetsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesThis tells the server to publish this prefix on the Router Advertisement messages on that interface. Without <tt>publish=yes</tt> the command tells the server that the fdcc:7c4e:3651:1:::/64 network is on the “Local Area Connection” interface for routing purposes – that the prefix for devices on this interface is (or will be) fdcc:7c4e:3651:1:::/64. The <tt>publish=yes</tt> bit tells the server to publish this prefix information in Router Advertisement messages.
 
Below is a Wireshark capture once prefix publishing is enabled:
 
[[Image:Bild54.png|top|alt="RA2"]]
 
Notice the prefix information is now published.
 
And now <tt>ipconfig</tt> too shows the automatically generated addresses:
# [[Image:Bild55.png|top|alt="ipconfig2"]]
# So far the server isn’t functioning as a router (i.e. it is not forwarding packets). If we want the server to function as a router that can be enabled:<br/>netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled
 
netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled# Once the server functions as a router we can also tell it to include this information in the Routing Advertisement messages. This way clients can automatically pick up the router as a default gateway!<br/>netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabled
 
netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabledChecking the Wireshark capture will now show a new option in the Router Advertisement messages:
 
[[Image:Bild56.png|top|alt="RA3"]]
 
And <tt>ipconfig</tt> will show a default gateway is automatically set:
 
[[Image:Bild57.png|top|alt="ipconfig3"]]
 
Ain’t that cool!
# To view the current configuration of that interface on the server, the following command can be used:<br/>netsh interface ipv6 show interface "Local Area Connection"
 
netsh interface ipv6 show interface "Local Area Connection"# The neat thing with Router Advertisement messages is that they can work in conjunction with DHCPv6. The Router Advertisement messages can tell clients to also contact DHCP for an IPv6 address and additional options, or contact DHCP ''not'' for an IPv6 address but only for additional options.<br/>For the former do this:<br/>netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabled
 
netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabledFor the latter do this:
 
netsh interface ipv6 set interface "Local Area Connection" otherstateful=enablednetsh interface ipv6 set interface "Local Area Connection" otherstateful=enabledHere’s the Wireshark output after I enabled managed address. The output is similar to the previous ones except for the flags (it’s <tt>0x80</tt> now in contrast to <tt>0x0</tt> before). So I have expanded it.
 
[[Image:Bild58.png|top|alt="RA4"]]
 
The way clients will behave now is thus:## If the client’s interface is set to Managed Address as disabled (i.e it is not looking for DHCPv6 address configuration), since the Router Advertisement now sets it to enabled it will start looking for DHCPv6 address configuration.
## If the client’s interface is set to Managed Address as enabled, since the Router Advertisement too sets it as enabled it will behave as before.
 
In the opposite scenario – suppose Router Advertisement messages were setting Managed Address as disabled (which is the default) clients ignore this and continue working based on what their own Managed Address configuration is.If you don’t want Windows clients to listen for Router Advertisements, do the following on the client:
 
netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
 
netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
 
As with the server, to view the interface configuration on the client the following works:
 
netsh interface ipv6 show interface "Local Area Connection"
 
netsh interface ipv6 show interface "Local Area Connection"
 
Lastly, suppose you have enabled prefix publishing on the server, and Wireshark shows the information is being sent but clients aren’t picking it up, the following might be helpful. By default the site prefix is set to /64 but if your network prefix is (say) /48 either by mistake or intentionally, clients will ignore this network prefix.
 
Correct the prefix setting then, or the network prefix mask if it’s a typo. The first time I played with this I had forgotten to change the mask from /48 to /64 once I added the subnet ID bits, so the server was advertising it with /48 and clients were ignoring it.
 
== Netsh-Befehle für IPv6 ==
[[IPv6/Windows/Netsh-Befehle]]


<noinclude>
== Anhang ==
== Anhang ==
=== Siehe auch ===
=== Siehe auch ===
Zeile 356: Zeile 33:
==== Links ====
==== Links ====
===== Weblinks =====
===== Weblinks =====
[[Kategorie:IPv6/Windows]]
</noinclude>
</noinclude>
[[Kategorie:Tmp]]
[[Kategorie:IPv6/Windows]]

Aktuelle Version vom 26. Januar 2024, 14:13 Uhr

IPv6 unter Windows

Option Beschreibung
Grundkonfiguration IPv6-Grundkonfiguration für Windows
IPv6 im Windows-Netz IPv6 im Windows-Netz
IPv6 unter Windows IPv6 unter Windows
DHCP mit IPv6 DHCP mit IPv6
IPv6-Support IPv6-Support
IPv6 Subnetz IPv6 Subnetz – Was ist das Richtige für mich?
Allgemein IPv6 Allgemein
IPv6-Labor IPv6-Labor
Teredo Microsofts Tunnelmechanismus Teredo
Router Advertisements IPv6 Router Advertisements on Windows
Netsh-Befehle Netsh-Befehle für IPv6


Anhang

Siehe auch

Links

Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=IPv6/Windows&oldid=92082“