IPv6/Windows: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „__KEIN_INHALTSVERZEICHNIS__“ durch „“
 
(11 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]]
 
== IPv6 im Windows-Netz ==
[[IPv6/WindowsIPv6ImWindowsNetz]]
 
== IPv6 unter Windows ==
[[IPv6/Windows/IPv6 unter Windows]]
 
== DHCP mit IPv6 ==
[[IPv6/Windows/DHCP mit IPv6]]
 
[[IPv6/Windows/IPv6Support]]
 
== 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.
 
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:
 
'''Site local: fec0:: '''
 
'''Subnetz prefix length: 64 '''
 
Gleiches Netz, andere Schreibweise:
 
'''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 ==
Nicht erst seit der Einführung von [http://www.msxfaq.de/verschiedenes/directaccess.htm Direct Access] und der Verknappung von IPv4-Adressen steigt das Interesse an IPv6. Auf der Seite [http://www.msxfaq.de/konzepte/ipv6.htm IPV6] habe ich generell erst den Microsoft Standpunkt zu IPv6 beschrieben. Nun möchten Sie aber vielleicht ihre ersten Schritte mit IPv6 gehen und wissen erst mal gar nicht, wo sie anfangen sollen. Diese Seite beschreibt die IPv6 Einführung bei Net at Work "intern" und die Hintergründe, wie wir IPv6 produktiv umgesetzt haben.
 
Aktuell fahren wir natürlich "noch" IPv4 parallel, weil es sehr viele Dienste gibt (z.B. Exchange 2010 uM, VoIP-Gateway), die noch nicht mit IPv6 umgehen können. Aber soweit möglich ist IPv6 präferiertes Protokoll.
 
Zudem ist es für den Einsatz von Direct Access ohne uAG erforderlich.
 
Wenn Sie nur ein Subnetz haben und eine IPv6-Verbindung zum Internet nutzen, dann können Sie problemlos mit der "Autokonfiguration" (APIPA) weiter arbeiten und sollten nicht durch eine vorschnelle Konfiguration ihr System vielleicht sogar verschlechtern* IPv6-Migrationsleitfaden für öffentliche Verwaltungen.
* [http://www.ipv6.bva.bund.de/ http://www.ipv6.bva.bund.de]
* [http://www.bit.bund.de/BIT/DE/Beratung/IPv6/node.html http://www.bit.bund.de/BIT/DE/Beratung/IPv6/node.html]
* "Kochbuch" für die IPv6-Einführung
* [http://www.bva.bund.de/cln_341/nn_2260316/DE/Aktuelles/Pressemitteilungen/2013/PM__Forschungsprojekt__IPv6__pdf.html http://www.bva.bund.de/cln_341/nn_2260316/DE/Aktuelles/Pressemitteilungen/2013/PM__Forschungsprojekt__IPv6__pdf.html]
* Migrationsleitfaden
* [http://www.bit.bund.de/cln_321/nn_2256370/BIT/DE/Shared/Publikationen/IPv6/fue__migrationsleitfaden.html http://www.bit.bund.de/cln_321/nn_2256370/BIT/DE/Shared/Publikationen/IPv6/fue__migrationsleitfaden.html]
* Profilhandbuch
* [http://www.bit.bund.de/cln_321/nn_2256370/BIT/DE/Shared/Publikationen/IPv6/fue__profildokument.html http://www.bit.bund.de/cln_321/nn_2256370/BIT/DE/Shared/Publikationen/IPv6/fue__profildokument.html]
* Sicher auch für Firmen durchaus interessante Quellen.
 
Bitte missverstehen Sie diese kurze Beschreibung nicht als universelle Anleitung für den Entwurf, die Planung und Einführung von IPv6 in ihrer Umgebung. Jede Firma hat auch bezüglich ihrer Größe besondere Anforderungen und ich bin wahrlich kein IPv6 Experte und kann mich irren. Feedback ist daher immer willkommen
 
=== Grundüberlegungen ===
IPv6 hat viel mehr Adressen (genau genommen 2 hoch 128), die aber so nicht komplett verwendbar sind. Um z.B. die Leitwege in Routern zu optimieren, werden sehr große Blöcke an Provider gegeben, die ihrerseits wieder gro0e Blöcke an Kunden geben können (z.B. 65536 Subnetze a 2^64 Hosts). Analog zu IPv4 gibt es auch bei IPv6 neben den "offiziellen" Adressen auch weiterhin private Adressen.
 
{| class="wikitable sortable options"
|-
|| '''IPv4'''
|| * 10.0.0.0 - 10.255.255.255
* 169.254.0.0 - 169.254.255.255
* 172.16.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.255.255
 
|-
|-
|| '''IPv6'''
! Option !! Beschreibung
|| * fc00:0000:000:000:0000:0000:0000:0000 - fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
 
|-
|}
 
Der Einsatz von privaten Adressen hat vor allem den Vorteil, dass man auch zukünftig recht sicher sein kann, dass man immer aktiv "umsetzen" muss, damit interne Systeme mit externen Systemen kommunizieren können. Ohne Proxy oder NAT ist keine Durchgängigkeit gegeben. So kann man die Investition in IPv6-Firewalls vielleicht noch etwas verzögern. Zudem hindert mich niemand daran, zukünftig auch offizielle Adresse parallel zu betreiben. Schon unter IPv6 hat ein Host ja mehrere IPv6 Adressen. Dann wird aber sich auch IPSec, welches quasi einfach mit "drin" ist, interessanter werden, um eine gegenseitige Authentifizierung der Endsysteme zu erzwingen Zudem müssen Sie sich dann nicht schon heute IPv6-Adressen von einem Provider besorgen.
 
Auf der anderen Seite wollten wir aber nicht mit ISATAP ein "virtuellen IPv6-LAN" über alle IPv4-Netze überspannen, so dass wir schon IPv6 auch durchgängig nutzen wollen.* RFC 4193: unique Local IPv6 unicast Addresses
* http://tools.ietf.org/html/rfc4193
* [http://en.wikipedia.org/wiki/Unique_local_address http://en.wikipedia.org/wiki/Unique_local_address]
 
=== Wahl der IPv6 Adressen ===
Damit wir nun die "richtigen" Adressen verwenden können, müssen wir uns erst mal mit den Adressen beschäftigen:
 
Wenn Sie IPv4 kennen, dann ist ihnen die Schreibweise der IP-Adressen xxx.xxx.xxx.xxx geläufig. IPv6 bedeutet nun nicht, dass die IP-Adresse plötzlich aus sechs stellen besteht. 111.222.333.444.555.666 ist keine gültige IPv6-Adresse. Die IPv6-Adressen besteht aus 8 Blöcken a 4 Hexadezimalzahlen:
 
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
 
Dabei gibt es mehrere Abkürzungen der Schreibeweise, die aber auf [http://www.wikipedia.com/wiki/Ipv6 www.wikipedia.com/wiki/Ipv6] sehr gut beschrieben sind. Bei IPv4-Adressen kann man anhand der ersten Nummern in den meisten Fällen auf die Subnet-Mask schließen, also die Definition, welcher Anteil das Netzwerk angibt und welcher Teil die Adresse in diesem Netzwerk beschreibt. Abweichungen können über die Subnet-Mask (Supernetting/Subnetting) definiert sind.
 
Bei IPv6 ist das alles etwas einfacher, da die hinteren 64bit einfach die MAC-Adresse der Ethernet-Karte sind und der vordere Teil das Netzwerk darstellt. Natürlich gibt es auch hier im Hostbereich unicast, Multicast und Broadcast Adressen und im Netzwerkbereich besondere Netzwerke.
 
Interessant ist hier auch , dass DNS-Server z.B. immer eine feste Adresse haben können, die zugleich eine Multicast-Adresse ist. Ein Client muss also nicht mehr nacheinander die verschiedenen DNS-Server fragen, die bislang zudem manuell oder per DHCP zu konfigurieren waren, sondern sendet eine Anfrage an das "Netz" und alle DNS-Server im LAN bekommen die Anfrage und antworten.
 
Auch die 127.0.0.1 hat eine Wandlung erfahren:&nbsp;
 
[[Image:Bild27.png|top|alt="ipv6 Ping auf Localhost"]]
 
Schauen wir uns die IPv6 Adressen mal etwas genauer an. Wesentlicher sichtbarer unterschied sind natürlich die neuen Adressen, welche aus 128 Bit bestehen, die sich in folgende Funktionen aufteilen.
 
+--------+-+------------+-----------+----------------------------+
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
 
Sie sehen also zuerst, dass es zwei mal 64bit sind, von denen die letzten 64 bit quasi den Endpunkt im "lokalen Subnetz" identifiziert. Also 2^64 Rechner in einem Subnetz.
 
Das klingt nach Verschwendung, speziell im Internet, weil Administratoren aus der IPv4-Welt ja schon Subnetting und Supernetting nutzen. Das wird bei IPv6 eigentlich nicht mehr verwendet. Der vordere Teil beschreibt das Netzwerk, wobei die ersten 7 Bit als Präfix folgende Funktion haben.
 
{| class="wikitable sortable options"
|-
|| '''Präfix'''
|| '''Pattern-Schreibweise'''
|| '''Scope'''
|| '''&nbsp;'''
|| '''Benennung'''
|-
|| ::/128
|| 0000:0000:0000:0000:0000:0000:0000:0000
|| entfällt
|| &nbsp;
|| Ungültige bzw. fehlende Adresse Vergleichbar zu 0.0.0.0
|-
|| ::1/128
|| 0000:0000:0000:0000:0000:0000:0000:0001
|| Loopback
|| Loopback
|| Vergleichbar zu 127.0.0.1
|-
|| fe80:/10
|| fe80:0000:0000:0000:0000:0000:0000:0000
 
febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff
|| Lokal
|| Unicast
|| Link Local unicast
 
Vergleichbar zu 169.254.x.x
|-
|| fec0:/10
|| fec0:0000:0000:0000:0000:0000:0000:0000
 
fecf:ffff:ffff:ffff:ffff:ffff:ffff:ffff
|| Lokal
|| Unicast
|| Site Local unicast (veraltet)
|-
|| fc00::/7
|| fc00:0000:0000:0000:0000:0000:0000:0000
 
fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
|| Global
|| Unicast
|| Unique Local unicast
 
Vergleichbar zu den privaten IPv4-Adressen 10.x.x.x, 172.16.x.x.x und 192.168.x.x
|-
|-
|| ff00::/8
| [[IPv6/Windows/Grundkonfiguration|Grundkonfiguration]] || IPv6-Grundkonfiguration für Windows
|| ff00::/8
|| &nbsp;
|| Multicast
|| &nbsp;
|-
|-
|| ff01::1
| [[IPv6/WindowsIPv6ImWindowsNetz|IPv6 im Windows-Netz]] || IPv6 im Windows-Netz
 
ff02::1
|| ff01::1
 
ff02::1
|| &nbsp;
|| Broadcast
|| All Nodes
|-
|-
|| ff01::2
| [[IPv6/Windows/IPv6 unter Windows|IPv6 unter Windows]] || IPv6 unter Windows
 
ff02::2
 
ff05::2
|| ff01::2
 
ff02::2
 
ff05::2
|| &nbsp;
|| &nbsp;
|| All Routers
|-
|-
|| 2000::/3
| [[IPv6/Windows/DHCP mit IPv6|DHCP mit IPv6]] || DHCP mit IPv6
|| &nbsp;
|| Global
|| Unicast
|| globalen unicast-Adressen, also routbare und weltweit einzigartige Adressen
|-
|-
|| 2001::/32
| [[IPv6/Windows/IPv6Support|IPv6-Support]] || IPv6-Support
|| 2001:0000:0000:0000:0000:0000:0000:0000
 
2001:ffff:ffff:ffff:ffff:ffff:ffff:ffff
|| Global
|| Unicast
|| Laut Wikipedia nicht genutzt (?)
|-
|-
|| 2001:0000::/32
| [[IPv6/Windows/IPv6 Subnetz|IPv6 Subnetz]] || IPv6 Subnetz – Was ist das Richtige für mich?
|| &nbsp;
|| Global
|| Unicast
|| Teredo ?
|-
|-
|| 2001:db8::/32
| [[IPv6/Windows/Allgemein|Allgemein]] || IPv6 Allgemein
|| &nbsp;
|| Global
|| Unicast
|| Laut Wikipedia für Beispiele (analog zur Domäne "example.com" und Dokumentationen zu nutzen
|-
|-
|| 2002::/16
| [[IPv6/Windows/IPv6-Labor|IPv6-Labor]] || IPv6-Labor
|| &nbsp;
|| Global
|| Unicast
|| 6to4 Tunnel-Adressen.
 
Jedes "öffentliche" IPv4 Subnetz wird so auf IPv6 abgebildet
 
[http://en.wikipedia.org/wiki/6to4 http://en.wikipedia.org/wiki/6to4]
|-
|-
|| 64:ff9b::/96
| [[IPv6/Windows/Teredo|Teredo]] || Microsofts Tunnelmechanismus Teredo
|| 0064:ff9b:0000:0000:0000:0000:0000:0000
 
0064:ff9b:0000:0000:0000:0000:FFFF:FFFF
|| Global
|| Unicast
|| NAT64. Die letzten 4 Byte (FFFF:FFFF) entsprechen der umgesetzten IPv4-Adresse
|-
|-
|| ::/96
| [[IPv6/Windows/Router Advertisements|Router Advertisements]] || IPv6 Router Advertisements on Windows
|| &nbsp;
|| &nbsp;
|| &nbsp;
|| IPv4 Kompatibilitätsadressen. Laut RFC4291 veraltet
|-
|-
| [[IPv6/Windows/Netsh-Befehle|Netsh-Befehle]] || Netsh-Befehle für IPv6
|}
|}


* IPv6
<noinclude>
* [http://de.wikipedia.org/wiki/IPv6#Adressbereiche http://de.wikipedia.org/wiki/IPv6#Adressbereiche]
* IPv6 Adressen
* [http://itbloggen.se/cs/blogs/hasain/archive/2010/09/01/ipv6-addressing.aspx http://itbloggen.se/cs/blogs/hasain/archive/2010/09/01/ipv6-addressing.aspx]
* [http://en.wikipedia.org/wiki/6to4 http://en.wikipedia.org/wiki/6to4]
* IPv4 Adressen in IPv6 abbilden.
 
Die nächsten 40 Bit kennzeichnen den Netzwerkblock, der über die 16 Subnet-ID weitere 65536 Subnetze zulässt. Laut RFC 4193 hat man die erwartete Bevölkerung im Jahr 2050 mit 9,3 Billionen angenommen und bei einer Teilung mit 40 Bits (also 2,199,023,255,552 Netze) pro Person 236 Prefixe zuteilen kann.
 
Die Anzahl ist sogar noch so groß, dass selbst eine zufällige Bestimmung dieser privaten Adressen es trotzdem recht unwahrscheinlich erscheinen lässt, dass die Adresse in einer anderen Firma genutzt wird. Und selbst wenn dies der Fall ist, gibt es ja immer noch weitere 16bit Subnetze, so dass eine doppelte Verwendung sehr unwahrscheinlich ist. Vorbei also, dass zwei Firmen beide ein 10er Subnetz haben und eine private Kopplung daran scheitert oder doppelt mit NAT gearbeitet werden muss.
 
Wenn Sie das Thema "Zufall" nicht selbst bedienen möchten, können Sie auf [http://www.simpledns.com/private-ipv6.aspx http://www.simpledns.com/private-ipv6.aspx] einfach ein Netz ermitteln lassen.
 
Andere nehmen einfach eine MAC-Adresse ihres Servers (da MAC-Adressen auch eindeutig sind) und nutzen diese als Netzmaske
 
Ich habe auch schon die E.164-Telefonnummer (z.B. fd49:5251:0304: verwendet)
 
So könnte eine interne IPv6 Adresse nach folgendem Schema aufgebaut sein:
 
[[Image:Bild28.png|top]]
 
FD ist das Präfix für private Adressen, die dann von der Länderkennung (49 = DE), dem Ortsnetz (5251 = Paderborn) und der Trunkleitung (304) gefolgt wird. Als "Subnet" nutzen wir einfach die gleiche Nummer, die wir auch dem VLAN auf den Switches vergeben haben.
 
Natürlich gibt es z.B. für Direct Access ein eigenes Subnetz, welches keinem physikalischen VLAN zugewiesen sind.* IPv6
* [http://de.wikipedia.org/wiki/Ipv6 http://de.wikipedia.org/wiki/Ipv6]
* Private IPv6 address range
* [http://www.simpledns.com/private-ipv6.aspx http://www.simpledns.com/private-ipv6.aspx]
* RFC4193 unique Local IPv6 unicast Addresses
* [http://www.ietf.org/rfc/rfc4193.txt http://www.ietf.org/rfc/rfc4193.txt]
* IANA IPv4 Address Space Registry
* [http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml]
 
=== Offizielle IP-Adressen ? ===
Vielleicht haben Sie sich gefragt, warum ich "FD"-Adressen verwende, also private Adressen, welche so im Internet eigentlich nie geroutet werden dürften.
 
Das hat erst einmal den Schutzgedanken. Würde ich offizielle Adressen verwenden und die Verbindung zwischen Internet und internem Netzwerk wäre vielleicht nicht optimal gesichert, dann wären die Systeme theoretisch erreichbar. Und es kann ja immer mal sein, dass ein update, eine KonfigurationsÄnderung oder eine
 
"Debug-Session" zur Fehlersuche die Filter außer Kraft setzt. Nein da bin ich konservativ und vertraue auf zusätzliche Hilfe in Form von Proxy-Servern, Relays etc., die aktiv meine Pakete über die Hürde tragen müssen und das Risiko deutlich gemindert ist.
 
Das zweite Problem könnte wie bei IPv4 könnte die Zuteilung einer Adresse sein. Zwar gibt es bei IPv6 deutlich mehr IP-Adressen und Subnetze aber ein wesentliches Ziel von IPv6 war die Vereinfachung der Leitwege im Internet, um die Router effektiver arbeiten zu lassen.
 
Und aufgrund der immensen Zahl von Subnetzen muss man nicht mehr wie am Ende der IPv4-Verfabe "einzelne Class-C"-Adressen an Provider vergeben, die dann in Leitwegen addiert werden mussten. Das sollte mit IPv6 anders gelöst werden.
 
Natürlich kann man auch bei IPv6 mit Subnetzen arbeiten, aber dies passiert nur noch auf den Leitwegen. In den Netzwerken selbst wird quasi immer ein 64er Subnetz angenommen.
 
[[Image:Bild29.png|top]]
 
Damit hat man zwar "sehr viele" Adressen in jedem einzelnen Netzwerk (2 hoch 64 = 18.446.744.073.709.551.616) aber die gleiche Anzahl ist ja noch mal an Netzwerken da. Wobei die ersten Stellen ja für eine Kennzeichnung des Netzwerks verwendet werden , so das hier ein paar Bit abgeknabbert werden. Da ein Kunde aber ja mehrere öffentliche Subnetze haben kann (z.B. auch intern eingesetzt) hat man das hinterste Feld des Netzwerks für Kundennetzwerke vorgesehen.
 
[[Image:Bild30.png|top]]
 
Das bleibt natürlich auch dem Provider überlassen. er bekommt von der Registry einen Block mit 64bit, wobei die ersten 16 Bits in der Regel eine 2001 sind.
 
Über den zweiten Block könnte man eine weitere unterteilung (65535) an Provider vergeben, die ihrerseits bis zu 65535 Subnetze an die Kunden geben können. Jeder Kunde hat dann weitere 65535 öffentliche Subnetze für die eigene Verwendung zur Verfügung.
 
Im Bezug auf das Routing müssten auf oberster Ebene eben nur max. 65535 Leitweger der Provider untereinander verwaltet werden und der Provider muss den Weg zu seinen "Kunden"-Zugängen routen, die ihrerseits mit 65535 Netzen viel Luft haben. Und wenn viele Kombinationen an der ersten Stellen sind noch gar nicht vergeben.
 
Sie sehen aber auch, dass für ein effektives Routing auch hier Subnetze üblicherweise vom Provider an Kunden vergeben werden. Eine "Freizügigkeit" ist natürlich auch denkbar, was aber wieder das einfache Routing aufweicht.
 
Daher werden die meisten Firmen doch wieder vom aktuellen Provider einen Netzbereich bekommen, der aber natürlich nur bedingt "freizügig" ist.
 
Um all das umgehen, sind private Adressen für intern aus meiner Sicht eine sehr gute Lösung.
 
=== IP-Adressvergabe: Autokonfiguration und DHCP ===
Mit dem Wissen über die verschiedenen Adressen sollte es ihnen nun einfach möglich sein, über ihre IPv4-Subnetze vergleichbar auch IPv6 Subnetze zu legen.
 
Wenn Sie nur genau ein Subnetz haben, dann müssen sie gar nichts machen, weil alle Clients immer auch eine "Link Local" Adresse mit dem Prefix fe80 haben und damit schon kommunizieren können.
 
Mit mehreren Subnetzen sollten Sie aber schon jedem Subnetz eine Adresse verpassen und diese natürlich an dem IPv6-Router konfigurieren. Der Router hat dann die besondere Funktion, regelmäßig eine sogenannte RA Messages (Router Announcement) zu versenden.
 
Wenn Sie in ihrem Netzwerk IPv6 mit "Unique Local IPv6 unicast Addresses" verwenden wollen, dann müssen Sie automatisch konfigurierten Clients die Adressen per DHCPv6 oder über die Auto-Konfiguration zuweisen.
 
Dazu muss aber ein System zumindest ein "Advertising" machen. Das entfällt natürlich bei komplett statisch vergebenen Adressen. Wie das geht, habe ich weiter unten bei "Router" beschrieben.
 
Die Clients "sehen" diese Meldung und mit einer generierten Hostadresse sind Sie dann schon im Netzwerken. Ein Client kann beim Hochfahren natürlich auch eine "Router Solicitation" Message senden, auf die alle Router in dem Subnetz umgehend antworten sollten.
 
Dann muss er nicht warten.
 
However, the advertisement frequency, which is usually about ten seconds or more, may seem too long for the end user. In order to redUCE this potential wait time, nodes can send Router Solicitation (RS) messages to all the routers on the link. Nodes that have not configured an address yet use the unspecified address "::". In response, the routers must answer immediately with a RA message containing a global prefix. This router solicitation corresponds to ICMPv6 messages of type RS, sent to the all-router multicast group: ff02::2. All routers on the link must join this group.
 
Quelle: IPv6 Autoconfiguration : [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/ipv6_autoconfig.html http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/ipv6_autoconfig.html]
 
Der passende Netmon filter wäre:
 
ICMPv6.MessageType == 0x85
oder
ICMPv6.RouterSolicitation
 
Damit kennt der Client die vorderen 64bit und darf sich nun eine Adresse für den Hostteil aussuchen. Meist wird er aus der MAC-Adresse gebildet. Bei aktivierte "Privacy"-Option ändert sich der Wert immer mal wieder, damit eben ein Webserver den Client nicht wiedererkennen kann.
 
Sie können natürlich auch einen DHCPv6 Server einsetzen, um den Client zu konfigurieren. In dem Beispiel wird z.B. der DNS-Server und der DNS-Domänenname per DHCPv6 verteilt. Alles andere erfolgt per Autokonfiguration.
 
Wenn Sie verhindern möchten, dass andere fremde Clients als DHCPv6-Server in ihrem Netzwerk stören, dann sollten Sie Pakete auf die UDP/TCP-Ports 546 und 547 auf den Ports in die passende Richtung sperren.
 
Allerdings müssen Sie eventuell auf der Netzwerkkarte des Client noch Optionen anpassen, damit "Additionales DHCPv6" möglich ist* Sollen nur zusätzliche Optionen (DNS, DNS-Namensbereich) bezogen werden, so genügt diese Konfiguration:
* netsh int ipv6 set int "LAN-Verbindung" otherstateful=enabled
* Möchte man auch die IP-Adresse via DHCPv6 managen lassen (Default bei Windows)
* netsh int ipv6 set int "LAN-Verbindung" managedaddress=enabled
 
In der Regel passen aber die Standardwerte.* IPv6-Konfigurationsmethoden
* [http://technet.microsoft.com/de-de/library/cc779656%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc779656(WS.10).aspx]
* IPv6-Adressbereich
* [http://technet.microsoft.com/de-de/library/cc781652%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc781652(WS.10).aspx]
* DHCPv6 - understanding of address configuration in automatic mode and installation of DHCPv6 Server
* [http://blogs.technet.com/b/teamdhcp/archive/2009/03/03/dhcpv6-understanding-of-address-configuration-in-automatic-mode-and-installation-of-dhcpv6-server.aspx http://blogs.technet.com/b/teamdhcp/archive/2009/03/03/dhcpv6-understanding-of-address-configuration-in-automatic-mode-and-installation-of-dhcpv6-server.aspx]
* RFC4861 Neighbor Discovery protocol
* [http://tools.ietf.org/html/rfc4861 http://tools.ietf.org/html/rfc4861]
* RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
* [http://tools.ietf.org/html/rfc3315 http://tools.ietf.org/html/rfc3315]
* RFC4862 IPv6 Stateless Address Autoconfiguration
* [http://tools.ietf.org/html/rfc4862 http://tools.ietf.org/html/rfc4862]
* RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
* [http://tools.ietf.org/html/rfc3736 http://tools.ietf.org/html/rfc3736]
* IPv6 Netzwerkgenerator.
* [http://www.simpledns.com/private-ipv6.aspx http://www.simpledns.com/private-ipv6.aspx]
* [https://www.sixxs.net/tools/grh/ula/ https://www.sixxs.net/tools/grh/ula/]
* Auch wenn diese private Adressen nicht registriert werden müssen, bietet SIXXS als Tunnelbroker eine Registrierungsseite an.
 
=== NDP - Neighbour Discovery Protocol ===
Nun hat ein Client also eine IP-Adresse und möchte natürlich auch seine Kollegen im gleichen Subnetz oder einen Router in ein anderes Subnetz erreichen. Auch wenn IPv6-Adressen länger sind, so ist darunter in den meisten Fällen immer noch Ethernet (oder WiFi) und dort zählen erst mal nur MAC-Adressen, von denen es drei Arten gibt* Unicast xx-xx-xx-xx-xx-xx
* Multicast (Ungerade Adresse)
* Broadcast FF-FF-FF-FF-FF-FF
 
IPv6 reduziert die Anzahl der Broadcasts extrem, da es intensiv mit Multicasts arbeitet, die dann immer nur eine Gruppen von Computern erreicht.
 
Wenn aber zwei Partner im gleichen Subnetz direkt miteinander kommunizieren wollen, dann nutzen sie natürlich unicast. Also muss es wie bei IPv4 eine Tabelle geben, welche IP-Adresse nun welche MAC-Adresse hat. Bei IPv4 sendet der Client einen ARP-Request als Broadcast, auf den der andere Server antwortet.
 
Bei IPv6 dienen dazu "Neighbor Solicitation"-Multicasts., die dann mit einem "Neighbor Advertisement" beantwortet werden. Aus den Antworten erstellt sich der Client selbst eine Liste der Nachbarn, die Sie mit "NETSH int ipv6 sh nei" abfragen können:
 
netsh interface ipv6 show nei
Schnittstelle 10: 192.168.100.20
Internetadresse Physische Adresse Typ
fd49:5251:304:1:192:168:100:10 00-15-5d-64-47-00 Abgelaufen
fd49:5251:304:1:192:168:100:11 00-15-5d-66-4e-02 Erreichbar
fd49:5251:304:1:192:168:100:30 00-15-5d-67-26-33 Abgelaufen (Router)
fd49:5251:304:1:192:168:100:31 00-0a-e4-0b-c1-8c Test
fe80::e8a9:5dd2:907:8c14 00-15-5d-67-26-33 Abgelaufen (Router)
ff02::2 33-33-00-00-00-02 Permanent
ff02::c 33-33-00-00-00-0c Permanent
ff02::16 33-33-00-00-00-16 Permanent
ff02::fb 33-33-00-00-00-fb Permanent
ff02::1:2 33-33-00-01-00-02 Permanent
ff02::1:3 33-33-00-01-00-03 Permanent
 
Neben den echten Hosts finden Sie hier auch jede Menge "Multicast"-Adressen, die eben IPv6 zur Selbstverwaltung nutzt.* Nachbarsuche (Neighbor Discovery, ND)
* [http://technet.microsoft.com/de-de/library/cc778019%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc778019(WS.10).aspx]
* Neighbor Discovery Protocol
* [http://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol http://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol]
 
=== Namensauflösung mit LLMNR und DNS-Server ===
Hinweis:
 
Im gleichen Subnetz nutzt IPv6 das Protokoll LLMNR (Link-Local Multicast Name Resolution [http://technet.microsoft.com/en-us/library/bb878128.aspx http://technet.microsoft.com/en-us/library/bb878128.aspx]) und kann so fast wie NetBIOS Broadcasts nach "kurzen" Rechnernamen suchen.
 
Vielleicht haben Sie sich schon mal die Karteikarte der IPv6 Konfiguration angeschaut. Hier gibt es im Vergleich zu IPv4 nun definitiv keinen WINS-Reiter mehr
 
[[Image:Bild31.png|top]][[Image:Bild32.png|top]]
 
Auch für die Namensauflösung haben sich die IPv6 Planer was nettes einfallen lassen. Da es ja "genug" freie Adresse gibt und Multicast zum guten Ton gehört, hat IPv6 einfach drei IP-Adressen (Multicast) für DNS vorgesehen, die sie an ihre DNS-Server vergeben sollte. Das geht bei Windows nicht über die GUI sondern nur per NETSH.
 
Zuweisen zusätzlicher IPv6 Adressen für DNS-Server
netsh interface ipv6 add address <Kartenname> FEC0:0:0:FFFF::1
netsh interface ipv6 add address <Kartenname> FEC0:0:0:FFFF::2
netsh interface ipv6 add address <Kartenname> FEC0:0:0:FFFF::3
 
Wenn Sie bei den Clients also keine abweichenden DNS-Server eintragen oder per DHCP vergeben, dann sollten Sie einfach ihren DNS-Servers diese Adresse zusätzlich geben. Wenn in dem lokalen Netz kein DNS-Server ist, dann sollten sie auf dem Router in dem Netz einen Leitweg zu einem DNS-Server addieren, der auf diese Adressen lauscht.
 
Im gleichen Zuge sollten Sie die "GlobalQueryBlocklist" eventuell anpassen, damit dort ISATAP zugelassen wird. Der Windows DNS-Server blockiert Anfrage an Namen in der Liste und liefert keine Antwort zurück. So wird z.B.: verhindert, dass ich ein Client den Namen ISATAP oder WPAD per dynamischen DNS registriert und Pakete von Client damit über sich leiten kann (Man in the middle)
 
Dies ist aber nur erforderlich, wenn Sie ISATAP auch verwenden möchten.
 
[[Image:Bild33.png|top]]
 
Bei Windows 2008 ist IPv6 für DNS scheinbar per Default aktiv. Bei Windows 2003 könnte es sein, dass Sie IPv6 Support erst noch aktivieren müssen.
 
REM Optional DNS-Server für IPv6 aktivieren
 
dnscmd /config /EnableIPv6 1
 
Wenn Sie schon beim DNS sind, dann können sie auch eine "Reverse Lookup"-Zone für ihr Subnetz anzulegen. Nur für den Fall dass Sie mal bei einem TraceRoute oder anderen Programmen zu einer IPv6-Adresse den Hostnamen suchen.
 
Integrating PTR resource record support into your DNS infrastructure is not recommended.
 
Quelle: [http://technet.microsoft.com/en-us/library/cc738372%28WS.10%29.aspx http://technet.microsoft.com/en-us/library/cc738372(WS.10).aspx]* IPv6-Konfigurationselemente
* [http://technet.microsoft.com/de-de/library/cc783049%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc783049(WS.10).aspx]
* Managing the Global Query Block List
* [http://technet.microsoft.com/en-us/library/cc794902%28WS.10%29.aspx http://technet.microsoft.com/en-us/library/cc794902(WS.10).aspx]
* Configuring DNS for IPv6/IPv4 Coexistence
* [http://technet.microsoft.com/en-us/library/cc738372%28WS.10%29.aspx http://technet.microsoft.com/en-us/library/cc738372(WS.10).aspx]
* RFC4074 Common Misbehavior Against DNS Queries for IPv6 Addresses
* [http://www.ietf.org/rfc/rfc4074.txt http://www.ietf.org/rfc/rfc4074.txt]
* Link-Local Multicast Name Resolution
* [http://technet.microsoft.com/en-us/library/bb878128.aspx http://technet.microsoft.com/en-us/library/bb878128.aspx]
* How to benefit from Link-Local Multicast Name Resolution.
* [http://blogs.technet.com/b/networking/archive/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution.aspx http://blogs.technet.com/b/networking/archive/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution.aspx]
* Disabling the Link Local Multicast Name Resolution (LLMNR) protocol when it is causing slowdowns for connections between newer workstations and older Windows XP / Windows 2003 servers
* [http://www.schoolleader.com/Documentation/Disabling_LLMNR_Causing_Slow_Networks.pdf http://www.schoolleader.com/Documentation/Disabling_LLMNR_Causing_Slow_Networks.pdf]
* Chapter 7 - Host Name Resolution
* [http://technet.microsoft.com/en-us/library/bb727005.aspx http://technet.microsoft.com/en-us/library/bb727005.aspx]
 
=== Gateway und Routing ===
Sie können bei der festen Vergabe einer IPv6-Adresse natürlich auch einen "Default Router" hinterlegen. Wenn der Client seine IPv6-Adresse aber anhand einer RA-Message selbst ermittelt, dann muss er irgendwie ja auch einen Weg in andere Subnetze kennen. Aber auch die Router untereinander wüssten gerne, welche Routen ein anderer Router kennt.
 
IPv6 hat dazu ein recht einfaches und pfiffiges System, indem die Router sich im "Netz" regelmäßig bekannt geben. Dies muss aber bei Windows erst aktiviert werden. Dazu sind zwei Schritte erforderlich:* Aktivierung der Funktion "Advertise" auf dem Interface
* Die ist eine Einstellung, die sie per netsh einstellen müssen. Advertising funktioniert nur, wenn auf der Schnittstelle auch für Routing aktiviert ist
 
REM Ausgeben der Liste von Schnittstellen zur Verwendung
 
netsh int ipv6 show interface
REM IPv6 Router Advertising einschalten
netsh int ipv6 set int <interfacenummer> adv=e rou=e
REM IPv6 Router Advertising abschalten
netsh int ipv6 set int <interfacenummer> adv=d rou=d* Advertising pro Route einrichten
* In der IPv6-Routingtabelle muss pro Route aktiviert werden, ob diese auch nach extern publiziert wird. Auch hier ist NETSH das Mittel zur Wahl
* [[Image:Bild34.png|top]]
 
REM Advertising für die Default Route ausschalten
netsh int ipv6 set route prefix="::/0" Interface="15" publish=no store=persistent
REM Advertising für die Default Route einschalten
netsh int ipv6 set route prefix="::/0" Interface="15" publish=yes store=persistent
 
ACHTUNG
 
Wenn Sie einen Default-Leitweg für IPv6 anlegen, dann lernen das die Clients quasi "sofort" und wenn dann noch DNS eine IPv6-Adresse liefern kann, wird der Client diesen Weg auch versuchen. Wenn also Webseiten einige Sekunden brauchen, weil der Browser erst IPv6 versucht und nach einem Timeout dann auf IPv4 zurück fällt, dann haben Sie hier die ursache.
 
Erst dann wird der Router auf den aktivieren Schnittstellen die freigegeben Routen auch bekannt geben. Die Funktion lässt sich am besten wieder per NETMON betrachten:
 
ICMPv6.MessageType == 0x86
oder
icmpv6.RouterAdvertisement
 
Etwas unschön bei IPv6 ist, dass die "link lokal" Adresse (Prefix:fe80) nicht einfach deaktiviert werden können und eine Router in ein entferntes Netz nicht zwingend dessen lokale unicast Adresse verwendet sondern eventuell die LinkLocal als Next Hop.
 
[[Image:Bild35.png|top]]
 
Das ist dann erst mal nicht so hilfreich bei der Ermittlung des nächten Hop. Zum Glück gibt es dann aber noch Tracert:
 
[[Image:Bild36.png|top]]
 
Auf Domaincontrollern ist z.B. das "Advertising" für Routen auch nicht aktiv. In einer Umgebung ohne Router muss man daher selbst Hand anlegen oder gleich auf die privaten Adressen verzichten und mit den dynamischen "fe80"-Adressen arbeiten.* Rogue IPv6 Router Advertisement Problem Statement
* [http://tools.ietf.org/html/rfc6104 http://tools.ietf.org/html/rfc6104]
* RFC4861 Neighbor Discovery protocol
* [http://tools.ietf.org/html/rfc4861 http://tools.ietf.org/html/rfc4861]
* RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
* [http://tools.ietf.org/html/rfc3315 http://tools.ietf.org/html/rfc3315]
* RFC4862 IPv6 Stateless Address Autoconfiguration
* [http://tools.ietf.org/html/rfc4862 http://tools.ietf.org/html/rfc4862]
* RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
* [http://tools.ietf.org/html/rfc3736 http://tools.ietf.org/html/rfc3736]
 
=== IPv6 auf Core ===
Windows 2008 gibt es auch als "Core-Version", bei der viele Komponenten des normalen Desktops entfallen sind. Das Problem dabei ist einfach, dass damit auch keine GUI zur Verwaltung von IPv6-Adressen vorhanden ist. IPv4-Adressen kann ein Admin vielleicht noch mit sconfig oder coreConfig eintragen, aber bei IPv6 ist die Kommandozeile per SCONFIG gefragt. Hier ein paar Beispiele:
 
REM Anzeige der aktuelen IPv6 Adressen
netsh interface ipv6 show address
REM addieren einer IPv6 Adresse
netsh interface ipv6 add address "Local Area Connection" fd49:5251:0304:1:192:168:100:10
REM Loeschen einer IPv6 Adresse
netsh interface ipv6 delete address "Local Area Connection" fd49:5251:0304:1:192:168:100:10
REM Host als Default Router publishen. Nethop ist der Server selst
netsh interface ipv6 add route ::/0 "Local Area Connection" nexthop=fd49:5251:0304:1:192:168:100:10 publish=yes
REM Routen "publishen"
netsh interface ipv6 add route fec0:0:0:1::/64 "Local Area Connection" publish=yes
netsh interface ipv6 add route fec0:0:0:2::/64 "Local Area Connection 2" publish=yes
 
So viel schlechter sind Sie mit einem Windows Core im Vergleich zu einem normalen Windows 2008 Server aber nicht gestellt, da über die GUI eigentlich nur IPv6-Adressen, Default IPv6-Gateway und IPV6-DNS-Server gepflegt werden können. Für alle anderen weiteren Einstellungen ist sowieso NETSH erforderlich.* The Cable Guy - September 2002 Manual Configuration for IPv6
* [http://technet.microsoft.com/en-us/library/bb878102.aspx http://technet.microsoft.com/en-us/library/bb878102.aspx]
* Windows Server 2008 R2 Core: Introducing SCONFIG.
* [http://blogs.technet.com/b/virtualization/archive/2009/07/07/windows-server-2008-r2-core-introducing-sconfig.aspx http://blogs.technet.com/b/virtualization/archive/2009/07/07/windows-server-2008-r2-core-introducing-sconfig.aspx]
* Core Configurator 2.0 (x64)
* [http://coreconfig.codeplex.com/ http://coreconfig.codeplex.com/]
 
=== Finales Netz ===
Wenn Sie all ihre VLANs dann mit entsprechenden IPv6-Subnetzadressen bedacht haben und ihre Router dann auch IPv6 richtig routen und auch die Routen im Netzwerk bekannt geben und auf Anfragen der Clients reagieren, dann sollten Sie ohne Probleme mit IPv6 arbeiten können. Vergessen Sie aber nicht die Dokumentation ihres Netzwerks
 
[[Image:Bild37.png|top]]
 
Dazu gehört natürlich auch eine Übersicht der Subnetze, der Hosts mit festen IP-Adressen und alle anderen manuell gemachten Einstellungen auf ihren Systemen. Wenn Sie dann aber IPv6 durchgängig installiert haben, dann können Sie sehr viel einfacher z.B. [http://www.msxfaq.de/verschiedenes/directaccess.htm Direct Access] einsetzen.
 
=== IPv6 Server und Client ===
Nun haben Sie IPv6 auf Servern und Clients etabliert und könnten z.B.: mit [http://www.msxfaq.de/verschiedenes/directaccess.htm Direct Access] auch eine sehr nette VPN-Lösung etablieren. Aber noch sind Sie nicht am Ziel. Ein Client, der mit IPv6 den Server erreichen will, muss diese IP-Adresse per DNS auflösen und den Server erreichen. Aber wichtiger ist noch, das die Client Software und die Server Software auch IPv6 verstehen und anbieten. Einen unvollständigen Überblick:
 
{| class="wikitable sortable options"
|-
|| '''Dienst'''
|| '''Beschreibung'''
|-
|| Active Directory (LDAP, GC, KDC
|| Funktioniert
|-
|| Windows DNS/DHCP
|| Funktioniert
|-
|| Windows Firewall
|| Konfigurierbar
|-
|| Windows RDP
|| Ja aber beachten Sie, dass Sie die Firewall-Regel auch die IPv6-Adressen enthalten sollten, wenn Sie den Zugriff beschränken
|-
|| IIS
|| Ja, aber diverse darauf aufsetzende Anwendungen noch nicht bzw. benötigen Anpassungen. Und wer die Bindungen auf bestimmte IP-Adressen konfiguriert, muss auch die IPv6-Adresse als Bindung addieren.
|-
|| Exchange 2007/2010
|| Ja, außer Exchange UM
|-
|| Lync
|| Nutzt IPv4
|-
|| SMB
|| Ja
|-
|}
Andere Dienste füge ich zu gegebener Zeit hinzu* How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to Direct Access connected machines
* [http://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-directaccess-connected-machines.aspx http://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-Direct Access-connected-machines.aspx]
 
=== NAT64, DNS64, 6to4 ===
IPv4 wird durch IPv6 sicher nach und nach abgelöst und in ein paar Jahren wird man im Internet vermutlich nur noch IPv6 sprechen. In internen Netzwerken ist der Druck vielleicht noch nicht so hoch, aber Direct Access und andere neue Techniken sprechen auch hier für IPv6. Dennoch wird es über der Koexistenzphase erforderlich sein, dass IPv4 mit IPv6 spricht. Beide Adressierungsschemata werden natürlich parallel und teilweise auch auf dem gleichen Kabel bzw. VLAN existieren.
 
Entsprechende Gateways werden die Pakete umsetzen müssen. Dabei gibt es beide Richtungen zu betrachten. Die Tabelle ist nur relevant, wenn es keine direkte Verbindung mit dem gleichen Protokoll gibt. Das gilt insbesondere für "Dual-Stack"-Systeme die beide Protokolle fahren können.
 
Da ist natürlich klar, dass die Verbindung 1:1 erfolgt, zumindest wenn die Dienste auch das jeweilige Protokoll unterstützen.
 
Wenn aber Client und Server nicht innerhalb der gleichen Version kommunizieren können, dann muss umgesetzt werden
 
{| class="wikitable sortable options"
|-
|| '''Client'''
|| '''Service'''
|| '''Namensauflösung'''
|| '''IP-Routing'''
|-
|| IPv4
|| IPv6
|| Der IPv4 Client kann schlimmstenfalls nicht mit einer IPv6 Adresse (AAAA) per DNS anfangen. Dem IPv6-Service muss demnach eine IPv4-Adresse zugeordnet werden. Davon muss der IPv6-Server sogar nicht mal was wissen. Die Zieladresse kann aber nicht direkt zum Service gehen, sondern muss auf einem Zwischensystem landen.
|| Das Zwischensystem nimmt dann die Pakete an die virtuelle IPv4-Adresse an und sendet das Paket seinerseits mit einer IPv6-Quelladresse an die IPv6 Zieladresse.
 
Der angesprochene Server antwortet an die IPv6-Quelladresse, die ebenfalls über das Gateway geroutet wird und dort wieder auf IPv4 umgesetzt wird.
|-
|| IPv6
|| IPv4
|| DNS64
 
Hierbei könnte der Client bei einer DNS-Anfrage nur eine IPv4-Adresse erhalten, weil das andere System nicht per IPv6 erreichbar ist. Damit kann der Client nichts anfangen. Daher muss der IPv6-DNS-Server mit einem Gateway Hand in Hand arbeiten und als DNS-Helper die Anfrage des IPv6-Clients annehmen, selbst dann den DNS-Server fragen und die zurückgelieferte IPv4-Adresse durch eine erreichbare IPv6-Adresse ersetzen.
 
Diese Funktion ist z.B. im uAG enthalten
|| NAT64
 
Das Gateway bedient nun alle IPv6-Adressen, die der DNS-Service als Ersatz heraus gibt und routet die IP-Pakete an das IPv4-System weiter.
 
Da hier das Quellsystem aber nur eine IPv6-Adresse hat, muss das Gateway aus einem lokalen IPv4-Pool schöpfen, an die der IPv4-Server auch wieder antworten kann.
 
Diese Funktion ist z.B. im uAG enthalten
 
|-
|}
 
=== NETSH Reset ===
Eine letzte Zeile zum Schluss:
 
netsh int ipv6 reset
 
Damit können Sie alle Einstellungen den IPv6-Stack wieder auf "Default" zurück setzen. Allerdings ist nach diversen anderen Artikeln ein Neustart des Systems erforderlich, dass die Einstellungen auch zum Tragen kommen.* Migrating IPv6.exe Commands to Netsh Command
* [http://technet.microsoft.com/en-us/library/bb726950.aspx http://technet.microsoft.com/en-us/library/bb726950.aspx]
* Using Windows Tools to Obtain IPv6 Configuration Information
* [http://technet.microsoft.com/en-us/library/bb726952.aspx http://technet.microsoft.com/en-us/library/bb726952.aspx]
* Netsh
* [http://en.wikipedia.org/wiki/Netsh http://en.wikipedia.org/wiki/Netsh]
* Netsh.exe
* [http://msdn.microsoft.com/en-us/library/windows/desktop/bb736546%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb736546(v=vs.85).aspx]
 
=== Weitere Links ===
* [http://www.msxfaq.de/verschiedenes/directaccess.htm Direct Access]
* [http://www.msxfaq.de/verschiedenes/directaccess2012.htm Direct Access 2012]
* [http://www.msxfaq.de/konzepte/ipv6.htm IPV6]
* [http://www.msxfaq.de/konzepte/isatap.htm ISATAP]
* IPv6
* [http://de.wikipedia.org/wiki/IPv6#Adressbereiche http://de.wikipedia.org/wiki/IPv6#Adressbereiche]
* IPv6
* [http://de.wikipedia.org/wiki/Ipv6 http://de.wikipedia.org/wiki/Ipv6]
* Private IPv6 address range
* [http://www.simpledns.com/private-ipv6.aspx http://www.simpledns.com/private-ipv6.aspx]
* RFC4193 unique Local IPv6 unicast Addresses
* [http://www.ietf.org/rfc/rfc4193.txt http://www.ietf.org/rfc/rfc4193.txt]
* IANA IPv4 Address Space Registry
* [http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml]
* IPv6-Konfigurationsmethoden
* [http://technet.microsoft.com/de-de/library/cc779656%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc779656(WS.10).aspx]
* IPv6-Adressbereich
* [http://technet.microsoft.com/de-de/library/cc781652%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc781652(WS.10).aspx]
* DHCPv6 - understanding of address configuration in automatic mode and installation of DHCPv6 Server
* [http://blogs.technet.com/b/teamdhcp/archive/2009/03/03/dhcpv6-understanding-of-address-configuration-in-automatic-mode-and-installation-of-dhcpv6-server.aspx http://blogs.technet.com/b/teamdhcp/archive/2009/03/03/dhcpv6-understanding-of-address-configuration-in-automatic-mode-and-installation-of-dhcpv6-server.aspx]
* RFC4861 Neighbor Discovery protocol
* [http://tools.ietf.org/html/rfc4861 http://tools.ietf.org/html/rfc4861]
* RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
* [http://tools.ietf.org/html/rfc3315 http://tools.ietf.org/html/rfc3315]
* RFC4862 IPv6 Stateless Address Autoconfiguration
* [http://tools.ietf.org/html/rfc4862 http://tools.ietf.org/html/rfc4862]
* RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
* [http://tools.ietf.org/html/rfc3736 http://tools.ietf.org/html/rfc3736]
* IPv6 Netzwerkgenerator.
* [http://www.simpledns.com/private-ipv6.aspx http://www.simpledns.com/private-ipv6.aspx]
* Nachbarsuche (Neighbor Discovery, ND)
* [http://technet.microsoft.com/de-de/library/cc778019%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc778019(WS.10).aspx]
* Neighbor Discovery Protocol
* [http://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol http://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol]
* IPv6-Konfigurationselemente
* [http://technet.microsoft.com/de-de/library/cc783049%28WS.10%29.aspx http://technet.microsoft.com/de-de/library/cc783049(WS.10).aspx]
* Managing the Global Query Block List
* [http://technet.microsoft.com/en-us/library/cc794902%28WS.10%29.aspx http://technet.microsoft.com/en-us/library/cc794902(WS.10).aspx]
* Configuring DNS for IPv6/IPv4 Coexistence
* [http://technet.microsoft.com/en-us/library/cc738372%28WS.10%29.aspx http://technet.microsoft.com/en-us/library/cc738372(WS.10).aspx]
* RFC4074 Common Misbehavior Against DNS Queries for IPv6 Addresses
* [http://www.ietf.org/rfc/rfc4074.txt http://www.ietf.org/rfc/rfc4074.txt]
* Rogue IPv6 Router Advertisement Problem Statement
* [http://tools.ietf.org/html/rfc6104 http://tools.ietf.org/html/rfc6104]
* RFC4861 Neighbor Discovery protocol
* [http://tools.ietf.org/html/rfc4861 http://tools.ietf.org/html/rfc4861]
* RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
* [http://tools.ietf.org/html/rfc3315 http://tools.ietf.org/html/rfc3315]
* RFC4862 IPv6 Stateless Address Autoconfiguration
* [http://tools.ietf.org/html/rfc4862 http://tools.ietf.org/html/rfc4862]
* RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
* [http://tools.ietf.org/html/rfc3736 http://tools.ietf.org/html/rfc3736]
* RFC6104 Rogue IPv6 Router Advertisement Problem Statement
* [http://tools.ietf.org/html/rfc6104 http://tools.ietf.org/html/rfc6104]
 
Quelle
 
[http://www.msxfaq.de/konzepte/ipv6lan.htm http://www.msxfaq.de/konzepte/ipv6lan.htm]
 
Teredo bohrt IPv6-Tunnel durch Firewalls
 
== 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]]
 
== Anhang ==
== Anhang ==
=== Siehe auch ===
=== Siehe auch ===
Zeile 988: 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“