Im Test: Autokonfiguration von IPv6-Clients

Horrormeldungen, dass die IPv4-Adressen ausgegangen sind, machen seit einiger Zeit die Runde. Die mittlerweile selbst schon in die Jahre gekommene Version 6 des Internet Protocol soll Abhilfe schaffen. Dieser Artikel untersucht, ob IPv6 im lokalen Netz schon eine vollwertige Alternative zu IPv4 darstellt. Aller Euphorie zum Trotz holte die Realität den Autor bei den ersten Untersuchungen aber schnell ein, sodass hieraus ein Bericht über einen Selbstversuch in einem reinen IPv6-Netz wurde.

Die Theorie

Wie sich ein Rechner in einem IPv6-Netz zurechtfindet, ist theoretisch in [1] beschrieben. Der RFC spezifiziert das Neighbor Discovery Protocol, das unter anderem das Address Resolution Protocol (ARP) ablöst. Es ist zuständig für die Zuordnung von MAC-Adressen zu IP-Adressen, findet aber auch die zuständigen Router für Adressen in anderen Netzen und verteilt optional Adress-Präfixe für das lokale Netz. Der Ablauf sieht dabei so aus:

• Sobald das Interface aktiv ist, wird ein Router Solicitation Request an die Multicast-Adresse »ff02::2« (alle Router im lokalen LAN-Segment) gesendet. Alle IPv6-Router in diesem Netz antworten darauf mit einem Router Advertisement.
• Abhängig von den Flags im empfangenen Advertisement konfiguriert der Client entweder automatisch eine IP-Adresse im empfangenen Präfix aus der MAC-Adresse im EUI64-Format (siehe Kasten "Adressen erzeugen mit EUI64") oder in der anonymisierenden temporären Version [2]. Das Flag dazu heißt »AdvAutonomous« .

• Wenn das »AdvManagedFlag« gesetzt ist, dient das "Administered Protocol" zusätzlich zur Autokonfiguration. Damit ist DHCPv6 gemeint. Sind beide Flags gesetzt, bezieht der Client eine Adresse per DHCP und vergibt sich selbst die automatisch konfigurierte.

Damit ist der Client im LAN erreichbar und findet auch seine Nachbarn. Außerdem kennt der Client die IPv6-Routen, um auch Rechner jenseits des LANs zu erreichen. Wenn kein DHCP verwendet wird, weiß der Client zum jetzigen Zeitpunkt aber weder, welchen Nameserver er verwenden soll, noch wo sich sonstige Netzwerkdienste befinden. Der RFC [3] definiert deshalb eine Erweiterung für die Router Advertisements, die den Clients auch den Nameserver mitteilen können.

Es gibt noch ein weiteres Flag, das hier eine Rolle spielt: Das »AdvOtherConfig« -Flag. Laut [1] und der Manpage des Radvd soll es in [4] erklärt sein. Die Dokumenthistorie verrät, dass es zwar aus dem RFC entfernt wurde, aber nicht deprecated, also noch gültig ist. Die Bedeutung dieses Flags ist laut Radvd-Dokumentation: "When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information." Also genau, dass DHCPv6 eingesetzt werden soll, um Dienste wie Nameserver und so weiter zu finden.

DHCPv6 verhält sich im Prinzip wie DHCP für IPv4, mit dem Unterschied, dass es keine Broadcasts (die es in IPv6 ja nicht mehr gibt) sondern eine Multicast-Adresse verwendet, und sich der DHCP-Server auf Port 547/UDP bindet. Zum Praxistest verwendete der Autor Systeme mit Linux (Gentoo), Windows 7 Ultimate und Mac OS X Snow Leopard.

Windows 7

Das Windows-Testsystem wurde als frische Installation mit Standardeinstellungen in einer VM mit Virtualbox aufgesetzt. Das Netzwerkinterface der VM war mit einem VLAN-Segment verbunden, in dem kein IPv4 gesprochen wurde (wie bei allen Testsystemen). Die Adresskonfiguration funktioniert bei Windows 7 wie erwartet beziehungsweise wie von den Router Advertisements vorgegeben: Alle Flags werden entsprechend umgesetzt (Abbildung 1). RDNSS-Support fehlt allerdings.

Abbildung 1: Musterschüler Windows 7: Abgesehen von RDNSS werden alle IPv6-Parameter richtig konfiguriert.

Ist DHCPv6 im Einsatz, erfährt das Client-System auch den Nameserver. Eine Untersuchung mit Wireshark förderte zutage, dass der Client lediglich nach einem Nameserver und der Liste der lokalen Domains fragt. Außerdem werden noch Microsoft-spezifische Optionen abgefragt. Damit erfährt der Client alles, was er im Microsoft-Netz benötigt, da er über DNS mittels Service Discovery (SRV Records für Dienste) alle Komponenten findet, die zum Funktionieren notwendig sind.

Im ersten Versuch gab es jedoch eine kuriose Besonderheit: Über einen WPAD-DNS-Eintrag wurde die IP-Adresse eines Webservers bekanntgegeben, der über die Datei »wpad.dat« eine Proxy-Autokonfigurationsdatei bereitstellt. In dieser befand sich der auch mit IPv6-Adresse auflösbare Webproxy im LAN, der auch über IPv4 verbunden war, also auf beide Welten zugreifen kann. Der BITS-Dienst, den Microsoft für die Patches verwendet, funktionierte damit auf Anhieb. Ebenso konnte ein nachinstallierter Firefox-Browser, der auf Autokonfiguration eingestellt war, auf den Proxy zugreifen.