IP Version 6 in Umgebungen mit Windows Server 2008

24. Februar 2010

Nicht nur die Windows-Server stehen mit den Bezeichnungen 2008 und 2008 R2 in neuen und aktualisierten Versionen zur Verfügung, auch bei den entscheidenden Protokollen „darunter“ tut sich viel Neues: Das Internet Protocol in der Version 6 (IPv6) bietet sich für den Einsatz an. Es ist zu erwarten, dass sich IPv6   immer häufiger auch in den Firmen durchsetzt. Hier zeigt mit John Howie, ein ausgewiesener Experte für diesen Bereich, wie Windows Server 2008 verwendet kann, um dieses neue Netzwerkprotokoll einzusetzen.

Beim Internet Protocol Version 6  handelt es sich genau genommen um eine ganze Reihe von Protokollen, die angetreten sind, um den heutigen Standard IPv4 bei den Internet-Protokollen abzulösen. IPv6 stellt mit seiner 64-Bit-Architektur grundsätzlich eine Reihe von Verbesserungen und Erweiterungen zur Verfügung, die unter anderem dazu dienen, für die stetig weiter voranschreitende Expansion des Netzes genügend IP-Adressen zur Verfügung zu stellen.

Informationen rund um das Thema Internet Protocol Version 6 sind auf der Seite des „Deutschen IPv6 Rat“ (German IPv6 Council) verfügbar. Dort findet der interessierte Leser nicht nur einen Beitrag zum Thema „IPv4 Adressmangel und Szenarien zur IPv4/IPv6 Koexistenz“, sondern kann sich auch darüber informieren, welche Provider in Deutschland dieses Protokoll bereits unterstützen.

IPv6 unter Windows und die Änderungen beim Windows Server 2008

Wer auf seinen Systemen ein aktuelles Betriebssystem betreibt, kann ziemlich sicher sein, dass dieses bereits IPv6 unterstützt. Microsoft bietet bei den Windows-Systemen ab Windows XP SP1 für alle folgenden Betriebssysteme wie Vista, Windows 7 oder den Windows Server 2003 diese Unterstützung standardmäßig an. Die Forschungsabteilung von Microsoft hat auch einen IPv6-Stack für Windows 2000 und NT entwickelt, der aber vom Hersteller nicht weiter unterstützt wird.

Erst ab den Vista-Systemen wird IPv6 bei der Installation automatisch mit auf den Rechner gebracht und aktiviert. Administratoren, die also in ihrem Netzwerk auch Rechner unter Windows Vista betreiben, haben somit IPv6 in ihrem Netzwerk installiert (solange sie es nicht explizit auf diesen Systemen deaktiviert haben).

Findet das Vista-System im Netzwerk keine IPv6-taugliche Infrastruktur-Hardware wie DHCP-Server oder Router, konfiguriert es sogenannte link-lokale Adressen. Dabei handelt es sich um lokale IPv6-Adressen. Wurde IPv6 auf einem XP-System ab SP1 einmal aktiviert, so kann auch dieser Rechner als entsprechender Client zum Einsatz kommen. Auf diesen Systemen können dann einige gängige Kommunikationsprotokolle wie beispielsweise der Webzugriff über HTTP und HTTPS direkt über IPv6 ausgeführt werden. Auch der Windows Server 2003 unterstützt bereits bei den meisten Kommunikationswegen das neue IP-Protokoll.

Mit dem Release von Windows Server 2008 hat Microsoft einige Änderungen sowohl bei den bekannten Features als auch am Betriebssystem selbst vorgenommen. Dies geschah, um IPv6 besser zu unterstützen und die allgemeine Sicherheit zu verbessern. Zwei Veränderungen fallen dabei sofort ins Auge: Das mit diesem Betriebssystem-Release zusätzlich zur Verfügung gestellte „Dynamic Host Configuration Protocol for IPv6“ (DHCPv6) und die erweiterte Unterstützung von IPv6-Adressen unter DNS. Diese Unterstützung betrifft dabei besonders die Anzeige und Registrierung der IPv6-Adressen. Aber es existieren noch zwei weitere Änderungen, die mindestens genauso wichtig sind.

Die erste Änderung betrifft eine Standardeinstellung des Windows Servers 2008: Wenn kein ISATAP-Router (Intra-Site Automatic Tunnel Adressing Protocol) zur Verfügung steht, wird der Server dieses Protokoll auch nicht anlegen. Wenn der Server durch Standardmaßnahmen wie DNS-Anfragen, der Überprüfung der HOST-Datei und einem Name-Broadcast den Hostname ISATAP nicht finden kann, ist diese Bedingung erfüllt und das Protokoll wird nicht verwendet.

Diese Sicherheitsmaßnahme verhindert, dass sich Knoten im Netzwerk, die ISATAP-Schnittstellen besitzen, mit dem Windows Server 2008 verbinden und dabei IPv6-Pakete verwenden, die in IPv4-Paketen gekapselt sind. Auf diese Weise würden diese Systeme nämlich Router Access Control Lists (ACLs) und auch Firewalls problemlos umgehen können.

Die Entwickler sind dabei von der Annahme ausgegangen, dass der Netzwerkadministrator solche IPv6-Verbindung durch „Einpacken“ in IPv4-Pakete explizit erlauben will, wenn der Hostname ISATAPF durch diese Standardmaßnahmen aufgelöst werden kann. Allerdings können ja auch durchaus Szenarien existieren, in denen der Netzwerkadministrator die ISATAP-Schnittstelle einschalten will, auch wenn sich kein ISATAP-Router im Netzwerk befindet.

Dies ist beispielsweise dann der Fall, wenn reine IPv6-Anwendungen unterstützt werden sollen. Der Administrator kann in diesen Fällen die ISATAP-Schnittstelle manuell einschalten und den Windows Server 2008 dazu veranlassen, eingehenden eingekapselten IPv6-Verkehr anzunehmen. Dies geschieht durch den folgenden Aufruf an der Kommandozeile:

netsh interface ipv6 isatap set state enabled

Es ist in diesem Zusammenhang wichtig darauf hinzuweisen, dass Windows XP, Windows Vista und Windows Server 2003 der ISATAP-Schnittstelle auf jedem Fall eine Adresse zuweisen, auch wenn der ISATAP-Hostname nicht aufgelöst werden kann. Diese Schnittstelle kann dann auch dazu verwendet werden, mit anderen Hosts zu kommunizieren, auf denen ISATAP aktiv ist.

Eine zweite erwähnenswerte Änderung beim Windows Server 2008 steht ebenfalls in Zusammenhang mit ISATAP. Wenn der Administrator in einer DNS-Zone auf einem 2008-basierten DNS-Server für ISATAP einen A-Resource-Record anlegt, wird dieser DNS-Server standardmäßig nicht auf DNS-Anfragen für den Hostnamen ISATAP reagieren. Auch dieses neue Merkmal wurde aus Sicherheitsgründen in den Server integriert:

Es verhindert, dass Anwender unabsichtlich oder auch böswillig eine Maschine mit dem Namen ISATAP starten. Sie würden damit veranlassen, dass ein A-Resource-Record im DNS angelegt wird, der dann entsprechend aufgelöst wird. Trägt eine Maschine den Namen ISATAP, so gehen alle anderen IPv6-Knoten im Netz davon aus, dass es sich bei diesem System um einen ISATAP-Router handelt. Sie werden deshalb versuchen eine Kommunikation mit diesem System aufzubauen, wobei sie in IP4-Pakete gekapselte IPv6-Pakte verwenden werden.

Sie werden dann im Rahmen der Autokonfiguration über die sogenannte „Router Solicitation“ versuchen, entsprechende IPv6-Adressen zu erhalten. Dies geschieht durch eine Anfrage an die Multicast-Adresse „ff02::2“, über die alle Router eines Segments erreichbar sind (Nähere Informationen zu diesem Vorgang sind auch in einem IPv6-Artikel auf Wikipedia zu finden). Antwortet die Maschine mit dem Namen ISATAP dann mit dem Präfix einer IPv6-Adresse, wird sie zum Standard-Router für den gesamten IPv6-Verkehr. Auf diese Weise könnte ein Administrator mit böswilligen Absichten allen Netzwerkverkehr abfangen.

Wer ISATAP als Teil seiner Migrations- und Übergangsstrategie eingeplant und dabei einen ISATAP-Server installiert und konfiguriert hat, kann das Windows Server 2008-basierende DNS einschalten, damit dieses dann Anfragen nach einem A-Resource-Record für den Hostnamen ISATAP bearbeitet. Dies geschieht durch Veränderungen eines Schlüssels in der Registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList

Bei diesem Schlüssel handelt es sich um eine mehrteilige Zeichenfolge (multi-string), die zwei Einträge beinhaltet: isatap und wpad (dieser Eintrag ist zudem sicherheitsrelevant!). Der Administrator muss an dieser Stelle einfach nur den Eintrag „isatap“ entfernen und den DNS-Server neu starten.

Er muss diese Änderung jedoch auf allen Servern vornehmen, auf denen die Zone(n) vorhanden sind, in denen der Eintrag ISATAP definiert ist. Auch das Kommandozeilen-Programm „dnscmd“ kann zu diesem Zweck eingesetzt werden. Wer weitergehende Informationen zur Konfiguration der lokalen Abfragensperrliste (global query block list) benötigt, findet bei Microsoft einen Artikel zum Download, in dem auch der Gebrauch des Werkzeugs „dnscmd“ erläutert wird. Einen weiteren Artikel in deutscher Sprache rund um die Abfragensperrliste stellt Microsoft im TechNet bereit.

Vor dem Start: Planung und Reorganisation für IPv6

Bevor ein Systemadministrator damit beginnen kann, seinen Windows Server 2008 für den Einsatz im IPv6-Netzwerk zu konfigurieren, muss er zunächst planen, wie er dieses Protokoll in seiner Netzwerk-Umgebung unterstützen will. Noch bevor er jedoch überhaupt mit dieser Planung starten kann, ist es zunächst einmal notwendig, einige grundlegende Informationen zu sammeln. Eine erste Entscheidung betrifft die Art der Adressen, die zum Einsatz kommen werden: Sollen durchgehend aggregierbare globale IPv6-Adresse (öffentlich) verwendet werden oder soll ein privater Adressraum zum Einsatz kommen?

Wer sich dazu entschließt, öffentliche IP-Adressen einzusetzen, benötigt ein IPv6-Adressen-Präfix von seinem ISP (Internet Service Provider). Wenn dieser Provider noch nicht in der Lage ist, IPv6 zu unterstützen, so ist es auch möglich, ein derartiges Präfix von einem Tunnel-Provider zu bekommen. Fällt die Wahl auf den Einsatz von privaten IPv6-Adressen, so sollten die IT-Verantwortlichen den Einsatz der sogenannten Unique Local Adresses (ULA) in Betracht ziehen, da dies der bevorzugte Weg beim Einsatz von IPv6 ist.

Die meisten Betriebssysteme und Anwendungen unterstützen zwar auch noch die „Site Local Adresses“, also standortlokale Adressen, die ausschließlich innerhalb der gleichen Organisation geroutet werden. Diese direkten Nachfolger der privaten IP-Adressen gelten aber als veraltet und sollten nach Möglichkeit nicht mehr zum Einsatz kommen. Wer die Unique Local Adresses einsetzen will, muss dazu auch einen entsprechenden Unique-Präfix besorgen.

Zu diesem Zweck existieren einige Webseiten wie die von SixXS,  auf denen ein Präfix generiert werden kann. Wir werden im weiteren Verlauf des Artikels noch auf einen besonderen Vorteil eingehen, den der Einsatz von „Site Local“-Adressen in Windows-Umgebungen dennoch bedeuten kann. Natürlich kann ein Netzwerkverwalter die privaten Adressen in der Zwischenzeit auch dazu einsetzen, in seinem Intranet bereits heute eine IPv6-Verbindungen zu ermöglichen, so dass er dann später den Wechsel zu den öffentlichen Adressen vollziehen kann.

Im nächsten Schritt gilt es für die Systembetreuer alle Endgeräte im Netzwerk zu überprüfen: Server, Laptop- und Notebook-Rechner sowie alle anderen Geräte wie VOIP-Telefone und alle mobilen Systeme. Sämtliche Geräte gleich welcher Art, die in Verbindung mit dem Netzwerk stehen, müssen entsprechend untersucht werden. Bei jedem dieser Geräte muss festgestellt werden, ob das darauf laufende Betriebssystem und die Anwendungen in der Lage sind, mit IPv6 zusammen zu arbeiten.

Da es in der Praxis extrem unwahrscheinlich ist, dass wirklich alle vorhandenen Geräte IPv6 unterstützen oder ein Upgrade-Pfad dafür angeboten wird, kann davon ausgegangen werden, dass im Firmennetzwerk noch für eine ganze Zeit auch weiterhin IPv4 unterstützt werden muss.

Zudem müssen die IT-Fachleute bei diesen Überprüfungen feststellen, welche der Systeme eine Migration oder einen Übergang unterstützen, wie etwa 6to4 (ein Tunnelmechanismus, der ebenfalls IPv6-Pakete über IPv4 transportiert) oder ISATAP. Glücklicherweise wurde IPv6 so entworfen, dass es mit IPv4 koexistieren kann und die Administratoren können beide Protokolle zusammen im Netzwerk betreiben, wenn dies notwendig ist.

Minimalforderungen für IPv6

In einem nächsten Schritt sollten die Systemverantwortlichen einen Blick auf die Infrastruktur ihres Netzwerks in Hinblick auf die Unterstützung von IPv6 werfen. Dazu gehören die Router und Gateways ebenso wie Firewalls, DHCP- und DNS-Server. Bei jedem Netzwerkgerät, das von sich aus keine IPv6-Unterstützung mitbringt und zudem keinen Möglichkeit für ein entsprechendes Upgrade bietet, müssen sich die IT-Fachleuten darauf verlassen, dass ihre Netzwerkinfrastruktur beziehungsweise die Geräte darin, Migrations- oder Übergangslösungen für diese Fälle bereitstellt.

Nur so kann eine IPv6-Verbindung zu allen Endgeräten aufgebaut werden. Als Minimalanforderung sind deshalb DNS-Server wie der Windows Server 2008 gefordert, die eine entsprechende IPv6-Unterstützung anbieten.
Der Autor schlägt aus seiner Erfahrung heraus vor, dass die Systembetreuer in dieser Phase ihr Netzwerk so umorganisieren, dass alle Netzwerkegeräte mit IPv6-Unterstützung miteinander verbunden sind. Durch diesen Schritt wird es möglich, dass der größtmögliche Teil des Netzwerks nativ unter IPv6 betrieben werden kann. Zudem können dann Migrations- und Übergangslösungen eingesetzt werden, um diejenigen Geräte zu unterstützen, die zwar IPv6-Fahigkeiten aufweisen, aber über einen Teil der Infrastruktur angebunden sind, der diese Unterstützung nicht bieten kann.

Eine wichtige Regel besteht darin, dass Administratoren bei den Server-Systemen, die IPv6 unterstützen, nicht darauf setzen, dass diese ihre IP6-Verbindungen über Migrationslösungen erreichen. Das gilt im besonderen Maße für Infrastruktur-Server oder solche Systemen, die regelmäßig unter großer Last laufen. Ein derartiges Vorgehen würde nicht nur den Zugriff zu diesen Endsystemen deutlich verlangsamen, sie kann im ungünstigsten Fall das gesamte Netzwerk destabilisieren.

Wer also in seinem Netzwerk Teile der Infrastruktur entdeckt hat, die IPv6 nicht unterstützen, dort aber Endgeräte vorfindet, die das neue Protokoll durchaus verwenden können, muss eine weitere Entscheidung fällen: Sollen hier die entsprechenden Übergangslösungen oder Migrationsansätze zum Einsatz kommen, um doch eine IPv6-Verbindung aufzubauen, oder will man in diesen Bereichen weiterhin auf IPv4 setzen. Fällt die Entscheidung, überall mit IPv6 zu arbeiten, so gilt es festzustellen, welche Technik einen guten Übergang ermöglicht.

Besitzen die betreffenden Endsysteme Netzwerkadressen, die öffentlich zu routen sind, also nicht aus den Bereichen 10.x.x.x, 172.16x.x bis 172.31.x.x. oder 192.168.xx stammen, so wird 6to4 sicher eine gute Lösung sein. Sie steht zudem standardmäßig bereit, um die IPv6-Verbindungen zu gewährleisten. Sind die Endgeräte mit privaten IP-Adressen aus den zuvor genannten Bereichen ausgerüstet und befindet sich zwischen diesen Systemen und dem IPv6-Bereich des Netzwerks kein Gerät, das eine Network Adress Translation (NAT) zwischen diesen Bereichen bietet, so ist ISATAP das Protokoll der Wahl.

Steht an dieser Stelle jedoch ein NAT-Gerät zur Verfügung, so kann der Netzwerkadministrator hier auch auf eine Technology zurückgreifen, die als Teredo bezeichnet wird. Für den Windows Server in der Version 2008 steht diese Funktionalität nur in der Client-Version zur Verfügung, während beim R2-Release des Betriebssystems ein Teredo-Server und eine Relay-Funktion zum Lieferumfang gehören. Näheres dazu ist auf den Microsoft-Seiten unter anderem in einem Artikel mit dem Titel „Internet Protocol Version 6, Teredo and Related Technologies in Windows Server 2008“  und im Artikel „Support for IPv6 in Windows Server 2008 R2 and Windows 7“ im Technet zu erfahren.

Das Einschalten der Basis-Funktionalitäten mittels Router-Anfrage

Wer in seinem Netzwerk Router einsetzt, die eine entsprechende Technik unterstützen, kann jeden Router in seiner Umgebung so konfigurieren, dass er jedem Subnetz ein eindeutiges Präfix für IPv6-Adressen übermittelt. Kommen durchgehend aggregierbare globale IPv6-Adresse (öffentliche Adressen) zum Einsatz, so stellt der ISP einen 48-Bit-Präfix zur Verfügung, das mit der Ziffernfolge „2001::/16 beginnt.

Die unteren 16 Bit der oberen 64 Bit dieser öffentlichen IP-Adresse stellen dabei den Site Level Aggregation Identifier (SLA ID) da, und können dazu verwendet werden, die eigene Site in Subnetze einzuteilen. Wer also beispielsweise das Präfix 2001:470:8097::/48 zugewiesen bekommt, kann seine Router für jede Schnittstelle mit Präfixe in folgender Reihenfolge konfigurieren: 2001:470:8097:1::/64, 2001:470:8097:2::/64, 2001:470:8097:3::/64 und so weiter.

Wer die Unique Local Adresses einsetzt, wird ein 48-Bit-Präfix zugewiesen bekommen. Dabei kann es sich beispielweise um eine Adresse der Art „fd37:533b:f40d::/48“ handeln, da diese „locally unique addresses“ mit einer Folge der Form „fd00::/8“ beginnen. Auch hier kommen wiederum die unter 16 Bit zum Einsatz, um jede Subnetz-Schnittstelle eindeutig zu identifizieren.
Wer schließlich die veralteten deprecated „local adresses“ (standortlokale Adressen) einsetzt, die mit der Zeichenfolge fec0::/10 beginnen, kann 54 der oberen 64 Bit der IPv6-Adresse dazu verwenden, seine Subnetze eindeutig zu identifizieren. Normalerweise beginnt eine solche standortlokale Adresse mit der Zeichenfolge fec0:0:0::/48, was 16 Bit zum Anlegen von 65 536 Subnetzen zur Verfügung stellt.

Administratoren müssen je nach den entsprechenden Anweisungen des Router-Herstellers in den Geräten sowohl die Fähigkeit zu Router-Anfrage als auch zur Router-Ankündigung (router solicitation and advertisements) und die eingebaute Verwaltungssoftware für Router-Tabellen einschalten. Dazu gehört beispielsweise das Routing Information Protocol for IPv6 (RIPv6).

Sind diese Router-Einstellungen erfolgt, bekommen die IPv6-fähigen Geräte im Netzwerk über den Prozess der Router-Anfrage IPv6-Adressen zugeteilt, die gerouted werden können. Durch diese Maßnahmen werden ebenfalls Default-Gateways festgelegt und die entsprechenden Netzwerkgeräte können untereinander via IPv6 kommunizieren. Stehen entsprechende globale Adressen zur Verfügung können die Geräte nun auch direkt über dieses Protokoll mit dem „IPv6-Internet“ kommunizieren.

Verbindung für den Rest: Migrations- und Übergangstechniken

Sind im eigenen Netzwerk einer, mehrere oder alle Router nicht in der Lage, die zuvor geschilderten Techniken zu unterstützen, kann eine IPv6-Unterstützung nur durch Einsatz der Migrations-und Übergangstechniken erreicht werden. Sowohl 6to4 als auch ISATAP setzen auf die Technik, die IPv6-Pakete in IPv4-Pakete zu kapseln. Bei diesem Vorgang kommt der Protokolltyp 41 für die IPv4-Pakete zum Einsatz. Aus diesem Grund ist es wichtig, dass die Administratoren beim Einsatz einer derartigen Migrationstechnik sicherstellen, dass Pakete mit diesem Protokolltyp ungehindert die Router im Netzwerk passieren können.

Wenn die Endsysteme also öffentliche IPv4-Adresse besitzen und sie (wie auf den Windows-Systemen) dann auch 6to4 unterstützen, haben sie eine 6to4-IPv6-Adresse zugewiesen bekommen. Diese ist leicht zu identifizieren, da sie mit 2002::/16 beginnt. Das bekannte Programm „ping“ kann dazu eingesetzt werden festzustellen, ob eine Verbindung zwischen Systemen und dem IPv6-Internet über 6to4-Adressen möglich ist. Das kann beispielsweise durch den folgenden Aufruf erfolgen:

ping -6 www.arin.net

Da es sich bei dieser Adresse um die „American Registry for Internet Numbers“ handelt, ist es möglich diese Seite mittels eines solchen Aufrufs im IPv6-Internet zu erreichen, wie der Screenshot im Bild 1 zeigt. Wer in seinem Netzwerk eine Kombination von 6to4- und globalen Adressen einsetzt, sollte sich der Tatsache bewusst sein, dass der Verkehr in beide Richtungen zwischen derartigen Knoten immer sowohl über das IPv4- als auch über das IPv6-Internet fließt. Dies geschieht dabei über ein öffentliches 6to4-Relais. Das kann jedoch die Performance stark beeinträchtigen, so dass Administratoren in diesen Fällen über den alternativen Einsatz von ISATAP nachdenken sollten.

Weiterhin ist es in beide Richtungen nicht möglich, eine Verbindung zwischen einem Netzwerkgerät mit einer 6to4-Adresse und einem Knoten mit einer „local unique“- oder „site local“- Adresse über ein öffentliches 6to4-Relais aufzubauen. Diese Situation kann dann eintreten, wenn einige der Endgeräte öffentliche und andere private IPv4-Adressen verwenden und private Router so konfiguriert wurden, dass sie eine Kommunikation zwischen diesen Systemen erlauben. Für derartige Szenarien empfiehlt es sich, dass die Administratoren ausschließlich private oder ausschließlich öffentliche IPv4-Adresse verwenden sowie exklusiv nur ISATAP zum Einsatz bringen.

Wie all diese Erläuterungen schon sehr deutlich zeigen, besteht beim Einsatz von privaten IPv4-Adressen und für den Fall, dass die verwendete Netzwerkinfrastruktur IPv6 nicht unterstützt, die beste Wahl für die IT-Verantwortlichen darin, eine IPv6-Verbindung mittels ISATAP zu ermöglichen. Dazu ist es notwendig, dass ein System innerhalb des eigenen Netzes als ISATAP-Router eingerichtet wird. Dieser Router wird dann im Normalfall zwei Netzwerkschnittstellen besitzen, von denen eine die öffentliche und eine die private Schnittstelle darstellt.

Eine öffentliche Schnittstelle wird dabei entweder eine globale IPv6-Adresse oder eine 6to4-Adresse in Verbindung mit einer öffentlichen IPv4-Adresse zugewiesen bekommen. Private Schnittstellen werden in einer derartigen Konfiguration eine ISATAP-Adresse erhalten. Dieses ISATAP-Router-System wartet auf der private Schnittstelle auf Router-Anfragen (router solicitation requests) und antwortet via Router-Advertisements. Auf privaten Schnittstellen ist der IPv6-Verkehr dabei innerhalb der IPv4-Pakete gekapselt.

Besonders in der Version als Server Core eignet sich der Windows Server 2008 sehr gut zum Einsatz als ISATAP-Router. Der einfachste Weg diesen Windows-Server zum einem ISATAP-Router zu machen besteht darin, im festgelegte öffentliche und private IPv4-Adressen zu geben und das System ISATAP zu nennen. Das System wird den Namen ISATAP im DNS registrieren, so dass es als ISATAP gefunden und angesprochen werden kann. Wie bereits am Anfang des Artikels erläutert, ist es dabei wichtig, ein auf dem Windows Server 2008 aktives DNS so zu konfigurieren, dass es die ISATAP-Anfragen korrekt bedient. Für jede private Schnittstelle muss der Windows Server 2008 dabei mit dem folgenden Kommando konfiguriert werden:

netsh interface ipv6 set interface (Interface)
forwarding=enabled advertise=enabled
netsh interface ipv6 add route (IPv6 48-bit address):
(16-bit subnet)::/64 (Interface) publish=yes

Die Zeichenkette “IPv6 48-bit address” steht dabei für das Präfix, das der Firma vom ISP zugeteilt wurde oder für die oberen 48 Bit der 6to4-Adresse. Für den eindeutiger Subnetz-Identifier der Schnittstelle steht hierbei „16-bit subnet“ und „Interface“ ist ein Platzhalter für den Namen der ISATAP-Schnittstelle beziehungsweise deren Indexnummer. Wem keine entsprechenden globalen Adressen oder 6to4-Präfixe für den Einsatz von ISTAP zur Verfügung stehen, der kann an dieser Stelle auch die entsprechenden lokalen („site local“ oder „unique local“) Adressen verwenden.

Sobald der ISATAP-Router konfiguriert ist und die anderen Systeme in der Lage sind, beim Start den Namen ISATAP richtig aufzulösen, bekommen sie IPv6-Adressen vom ISATAP-Router zugewiesen, die gerouted und im DNS eingetragen werden. Wer die Konfiguration auf laufenden Systemen bereits vor dem nächsten Neustart erzwingen will, kann dies durch den folgenden Befehl erreichen:

ipconfig /renew6

Die weitere Konfiguration: DNS-Clients und der Einsatz von DHCPv6

Selbst wenn die Maschinen im Netzwerk nun bereits grundsätzlich in der Lage sind, über das Protokoll IPv6 zu kommunizieren, wird es Schwierigkeiten bereiten, eine derartige Verbindung auf dem Anwendungs-Level aufzubauen, wenn es im Netzwerk nicht möglich ist, vollqualifizierte Domänen- oder Host-Namen aufzulösen.

Wer jedoch in seinem Netzwerk IPv4 und IPv6 Seite an Seite betreibt und zudem sichergestellt hat, dass die DNS-Server via IPv4 erreicht werden können, sollte keine Probleme mit der Registrierung und Namensauflösung von IPv6-Adressen in der eigenen Umgebung und im Internet haben.

Jedes Windows-Client-System geht davon aus, dass DNS-Server auf den Site-lokalen Adressen fec0:0:0:ffff::1, fec0:0:0:ffff::2, und fec0:0:0:ffff::3 auf Anfragen warten. Administratoren, die nur IPv6 in ihrer Umgebung einsetzen und gewillt sind, standortlokale Adressen (site local adressing) einzusetzen, können Windows die Suche nach den DNS-Servern erleichtern. Das gelingt, indem sie ihre Subnetze so konfigurieren, dass diese eine DNS-Client-Konfiguration unterstützen.

In diesem Zusammenhang ist noch einmal der Hinweis wichtig, dass es möglich ist, die unterschiedlichen Adressen, wie globale, standortlokale oder auch link-lokale Adressen und ISATAP-Adressen gleichzeitig einzusetzen. Systemverwalter, die aber keine standardortlokalen Adressen einsetzen wollen, nur um die DNS-Clients im Netz zu unterstützen, können das folgende Kommando einsetzen, um Windows so zu konfigurieren, dass ein anderer DNS-Server verwendet wird:

netsh interface ipv6 add dnsserver (IPv6 address)

In reinen IPv6-Netzwerken kann der Administrator statt der zuvor geschilderten Router-Einstellungen auch DHCPv6 dafür einsetzen, seine Endsysteme mit den entsprechenden IPV6-Adressen zu versehen. Damit dieses Protokoll im Netzwerk richtig arbeiten kann, müssen die Router in der Lage sein, als DHCPv6-Relay-Server zu arbeiten. Dieses Protokoll kann auch sehr gut in kleinen isolierten Netzwerkumgebungen zum Einsatz kommen, in denen keine Router verwendet werden, um so mit seiner Hilfe IPv6-Verbindungen zwischen den Systemen zu ermöglichen.

Die Arbeitsweise von DHCPv6 entspricht im Prinzip der, die Administratoren von DHCP kennen. Ein grundsätzlicher Unterschied besteht darin, dass zunächst ein /64-Präfix spezifiziert wird, bevor der Adressbereich innerhalb des Subnetzes festgelegt wird, aus dem IPv6-Adressen zugeteilt werden sollen. Außerdem stehen bei DHCPv6 weniger Bereichsoptionen zur Verfügung, als dies unter DHCP der Fall ist.

Genau wie unter DHCP üblich, kann der Administrator auch DHCPv6 dazu verwenden, zusammen mit den festgelegten IPv6-Adressen auch die Liste der DHCP-Server anzubieten, die von den Knoten zur Namensauflösung verwendet werden sollen.

Der Einsatz von DHCPv6 bringt im Gegensatz zum Konfiguration von standortlokalen Adressen unter Windows einen Vorteil mit sich: Es ist so möglich, die IP-Adressen von DNS-Servern auch in unterschiedlichen Subnetzen anzubieten. Auf diese Weise kann dann eine höhere Ausfallsicherheit erreicht werden. Beim Einsatz eines Windows Servers 2008 steht dem Administrator zudem eine weitere Möglichkeit zur Verfügung:

Er kann den DHCPv6-Server so einstellen, dass er nur die Liste der IPv6-Adressen von DNS-Servern und der Domänen-Suffixe zur Verfügung stellt. Dies ist dann sinnvoll, wenn der Administrator DHCPv6 nicht dazu verwenden will, die Lease-Adressen zu vergeben, sondern diese Adressen weiterhin über die Router zugeordnet werden sollen.

Ein Bereich, den der Autor in diesem Artikel nicht betrachtet hat, betrifft den Einsatz von IPv6 im VPN (Virtual Private Network). Mit der weiteren Verbreitung von Windows 7 und Windows Server 2008 im R2-Release sollen derartige Verbindungen immer mehr durch den Einsatz der Technik „Direct Access“ ersetzt werden. Dabei kommen die bereits kurz erwähnte Technik mit der Bezeichnung Teredo im direkten Zusammenspiel mit IPv6 IPSec sowie ein neues Feature mit der Bezeichnung IP-HTTPS zum Einsatz.

Mit IP-HTTPS sollen IPv6-Pakete über einen HTTPS-Tunnel verschickt werden können, wenn Teredo nicht zur Verfügung steht oder blockiert ist. Auch zu diesen Themen steht auf Microsofts TechNet ein umfassender Artikel bereit.

John Howie/fms

Lesen Sie auch