© stillfx, 123RF

Die IPv6-Variante von DHCP hält ein paar Tücken bereit, die zwar im RFC stehen, jedoch eine gleichförmige Adressenvergabe schwierig machen. Es sind derzeit nur wenige freie DHCPv6-Server im Spiel, von einem davon, Dhcpy6d aus Dresden, soll hier die Rede sein.

Ein IPv6-LAN benötigt für die Adressenvergabe nicht unbedingt einen DHCP-Dienst, denn es gibt Autokonfigurations-Mechanismen. Ohne spezielle Erweiterungen teilen diese dem Client allerdings keinen DNS-Server mit, sodass für größere Netze in der Praxis doch ein DHCP-Server nötig wird.

Seit Juli 2003 definiert RFC 3315 [1] das DHCPv6-Protokoll. Einige der Änderungen gegenüber IPv4 sind langen Adressen geschuldet und dem Umstand, dass IPv6 keine Broadcasts kennt. Stattdessen gibt es eine dedizierte DHCP-Multicast-Adresse [2]. Auch die DHCP-Ports sind andere (UDP 546 beim Client, 547 beim Server). Über optionale Felder kann das Protokoll wie DHCPv4 Konfigurationsinformationen zu NIS+, SIP, NTP und weiteren Diensten transportieren.

Gängige Adressenverteiler im Linux-Lager sind Dibbler [3], ISC DHCPv6 [4] sowie Wide DHCPv6 [5], dessen Entwicklung aber ins Stocken geraten ist.

Was das bestehende IP-Adressenvergabe-Konzept gänzlich über den Haufen wirft, ist die DUID, die jeder DHCPv6-Client bei seinem ersten Aufruf errechnet und in einer Datei ablegt. Laut Paragraph 9 des RFC ist der DHCP Unique Identifier die einzige Eigenschaft, an der ein Server seine Clients – und umgekehrt – erkennt und erkennen darf. Im RFC steht sogar: “Clients und Server DÜRFEN NICHT auf andere Weise DUIDs interpretieren.”

Der Client und seine DUID

Die DUID lässt sich auf drei Arten generierten:

• Zeitstempel plus Linklayer (bei Ethernet die MAC-Adresse),
• eine Enterprise-ID plus ein variabler Anteil oder
• nur die Linklayer-Adresse.

Letzteres klingt zwar nach MAC-Adresse wie bei der statischen Zuordnung von IPv4-Adressen, ist es aber nicht (nur). Der RFC sagt hier: “Dieser DUID-Typ besteht aus zwei Octets mit einer DUID vom Typ 3, einem zwei Octets langen Netzwerkhardware-Typecode, gefolgt von der Linklayer-Adresse eines Netzwerkinterface, das permanent mit dem Client- oder Serverdevice verbunden ist.” Hier soll also das Gerät, nicht (allein und eindeutig) die MAC-Adresse der Karte mit eingehen (Abbildung 1).

Abbildung 1: Die ID einer IPv6-Adresse bildet sich aus der MAC-Adresse. Hierzu werden »FFFE« eingeschoben und das zweite Bit im ersten Byte gekippt.

Die Hardware-Adressen-Informationen ermittelt in der IPv6-Welt das ICMPv6-Protokoll auf der Schicht 3 – bei IPv4 macht das noch das Address Resolution Protocol (ARP) in Schicht 2. Die Entwickler haben diesem Vorgang auch einen neuen Namen gegeben: Neighbor Discovery Protocol (NDP, [6]).

Der formale Ansatz ohne die harte Bindung an die MAC-Adresse erscheint im ersten Moment klug, weil er ein Gerät im Netz auf allen Interfaces gleichermaßen erkennbar macht. In einer virtualisierten Welt führt dies aber zu Problemen, sobald der Admin ein Gerät klont. Denn viele DHCP-Client-Implementierungen generieren den DUID-Wert nur ein Mal und vergleichen ihn nie wieder mit den bestehenden Interfaces. Im Positiven führt das dazu, dass der Admin nach dem Tausch einer Netzwerkkarte nichts an der DHCP-Konfiguration ändern muss. Im negativen Fall bekommen beim Klonen einer virtuellen Maschine alle Kopien des Masters die gleiche Adresse, weil der DHCPv6-Server sie für dieselbe Maschine hält.

Wider den Standard

Das frühere Adressenmanagement-Tool am Institut für Festkörper- und Werkstoffforschung in Dresden basierte aber auf der eindeutigen Zuordnung von MAC-Adressen zu IP-Adressen. Erste Experimente mit IPv6 im Jahre 2009 brachten Henri Wahl, der an dem Institut arbeitete, die Erkenntnis, dass die automatische Konfiguration über die verteilten Präfixe nicht ausreicht. Daher begann er Dhcpy6d zu entwickeln. Wie der Name des Tools erkennen lässt, hat Wahl es in Python geschrieben. Nach einigen Jahren Betrieb im Institut hat er die Software 2012 auf Github [7] veröffentlicht. Alternativ kann sie jeder von der Homepage des Projekts [8] herunterladen.

Die Software verstößt absichtsvoll gegen die in diesem Kontext problematischen Anforderungen des RFC. (Auch der ISC-DHCP-Daemon kennt mittlerweile die Option, dass er aus der DUID des Clients die MAC-Adresse extrahiert, um so eine Konfiguration auf Basis der MAC-Adresse zu ermöglichen.) Beim zweiten Lauf geht der Dhcpy6d den umgekehrte Weg. Der Client schickt eine DUID und der Server vergleicht sie mit dem Eintrag in »hardware ethernet« , nicht umgekehrt.

Wenn also nach einem Hardwarewechsel eine neue MAC-Adresse, aber die alte DUID kommt, funktioniert noch alles und der Zusammenhang zwischen MAC und IP ist aufgehoben. Neben der MAC-Adresse erlaubt die Software aber auch die Identifikation über die DUID, wie der RFC sie vorsieht.

Dhcpy6d’s Sortierlogik

Dhcpy6d unterscheidet drei Konzepte, um Clients ihre Konfiguration zuzuordnen: Klassen, Adressenbereiche und Clients. Eine Klasse bestimmt Parameter, die für eine Gruppe von Clients gelten sollen, zum Beispiel den Nameserver und den Default-Router. Ob ein Client zu einer Klasse gehört, steht entweder explizit beim Client oder es ist möglich, über Filter nach Hostnamen, MAC-Adressen oder DUIDs (mit Python Regular Expressions) eine Zuordnung vorzunehmen.

Als letzte Eingrenzung, um Clients in Klassen zu ordnen, nimmt Dhcpy6d die Schnittstelle in der Form: Alle Requests, die über Netzwerkkarte 1 reinkommen, sind Klasse A, und alle über Karte 2 gehören zur Klasse B. Das setzt voraus, dass der Dhcpy6d in jedem relevanten Netz ein Standbein hat. Über ein DHCPv6-Relay Netzbereiche zuzuordnen ist nicht vorgesehen.

Ein Client dagegen beschreibt ein einzelnes Gerät, ihm darf der Admin einen Hostnamen sowie eine explizite Adresse zuordnen. Wichtig ist, dass in der Definition eines Clients steht, zu welcher Klasse er gehört. Alle Clients, die nicht explizit aufgelistet sind, kommen per se in die Klasse Default, und die Parameter, die Dhcpy6d für diese Klasse anwendet, gelten automatisch für sie.

In einem Adressenbereich steht das Muster, nach dem der DHCP-Server IPv6-Adressen für eine Klasse vergibt. Beim Adressenbereich 2001:db8::$mac$ beispielsweise hängt er an das Präfix 2001:db8::/64 einfach die MAC-Adresse des Clients an. Die Zuordnung zwischen Klasse und Adressenbereich erfolgt “one to many” – Mitglieder einer Klasse können Adressen aus mehreren Adressenbereichen zugewiesen bekommen.

Innerhalb des Adressenbereichs legt Dhcpy6d zudem fest, wie lange die Zuweisung gültig sein soll, ob es DNS-Updates geben wird und in welche Zonen der Client eingetragen werden soll.

Installation und Setup

Die Software läuft auf Linux, Free-, Net-, Open BSD sowie Apple OS X. Im Test zu diesem Artikel unter Gentoo Linux kam die Version aus dem Git-Repository zum Einsatz. Für RPM- und Deb-basierte Distributionen hält [8] Pakete zum Download bereit. Die Software benötigt einen Python-Interpreter in der Version 2.6 (besser 2.7), das Paket Dnspython für die Updates des Nameservers sowie das Python-MySQL-Modul, wenn MySQL als Datenbank ins Spiel soll. Kommt alternativ SQlite zum Einsatz, müssen das entsprechende Paket und der zugehörige Python-Support installiert sein.

Neben den Abhängigkeiten, die das Python-Programm Dhcpy6d selbst mitbringt, gibt es noch ein paar ausgelagerte Skriptdateien, die Module enthalten. Nach einem »git clone« ist die Software aber im Verzeichnis direkt lauffähig. Der Admin sollte beim Start darauf achten, dass er wirklich Python 2.7 verwendet, etwa indem er explizit das »python2.7« -Binary aufruft.

Dhcpy6d speichert die Leases in einer SQlite- oder MySQL-Datenbank. Zum Initialisieren der Tabellen dient eine mitgelieferte SQL-Datei, mit deren Hilfe das Kommando

sqllite volatile.db < doc/volatile.sql

die SQlite-Datenbank erzeugt. Die Webseite des Projekts beschreibt, wie sich die MySQL-Datenbanken und auch Clientlisten initialisieren lassen.

Den Server bekannt machen

Bevor Clients in einem LAN-Segment überhaupt versuchen ihre Adressen und die Konfiguration per DHCPv6 zu beziehen, müssen sie erfahren, dass in ihrem Netz ein DHCPv6-Server bereitsteht. Ein Client, der seine IPv6-Konfiguration aktiviert, schickt am Anfang eine Router-Solicitation. Daraufhin erhält er vom Router (oder den Routern) eine Antwort. Wenn im Präfix der Antwort (Router Advertisement) das Unmanaged-Flag steht, fordert das den Client dazu auf: Bau dir aus dem Präfix deine eigene Adresse, etwa über die EUI-64-Methode (64-Bit Extended Unique Identifier, [9]) oder eine zufällige für anonyme Adressen.

Steht das Flag auf Managed, ist dies die Aufforderung, den DHCPv6-Prozess anzustoßen. Also muss der Router im Netz, auf dem der Dhcpy6d arbeitet, dieses Managed-Flag in seinen Advertisements setzen. Die Webseite des Projekts schlägt folgende Konfiguration für den recht gängigen Radvd (Linux IPv6 Router Advertisement Daemon, [10]) vor:

interface eth0 {
AdvSendAdvert on;
AdvManagedFlag on;
};

Dabei soll der Radvd explizit das Präfix nicht announcen.

Die “dhcpy6d.conf”-Datei

Die beschriebene Logik bildet Dhcpy6d auf zwei Konfigurationsdateien ab: »dhcpy6d.conf« und »client.conf« . Letztere enthält die Einträge für die Clients, das Gleiche darf aber auch eine relationale Datenbank tun.

Die Datei »dhcpy6d.conf« unterteilt sich in Sektionen, deren Namen in eckigen Klammern stehen. Die allgemeinen Konfigurationsparameter sammelt der Block »[dhcpy6d]« . Listing 1 zeigt die im Test verwendete Datei. Die Zeile 2 legt die Schnittstelle fest, auf der der Dienst arbeitet. Es sind mehrere, durch Leerzeichen getrennte Einträge möglich.

01 [dhcpy6d]
02 interface = eth1
03
04 store_config = file
05 store_file_config = ./client.conf
06
07 store_volatile = sqlite
08 store_sqlite_volatile = ./volatile.sqlite
09
10 log = on
11 log_file = ./dhcpy6d.log
12
13 really_do_it = yes
14
15 dns_update = yes
16 dns_update_nameserver = 2001:db8:5::1
17 dns_rndc_key = rndc-key
18 dns_rndc_secret = FmZGJuHr/4+LkuxBc628Qg==
19 dns_use_client_hostname = no
20 domain_search_list = lmtest
21
22 [address_default]
23 category = mac
24 pattern = 2001:db8:1::$mac$
25
26 [address_special]
27 category = mac
28 pattern = 2001:db8::$mac$
29 dns_update = yes
30 dns_zone = lmtest
31 dns_rev_zone = 8.b.d.0.1.0.0.2.ip6.arpa
32
33 [class_special]
34 addresses = special
35 nameserver = 2001:db8:5::1

Die Zeilen 4 und 5 bestimmen, wo die Client-Definitionen stehen und deren Form als Textdatei. Wer bei »store_volatile« »none« angibt, verhindert, dass Dhcpy6d einzelne Clients verarbeitet. Statt »file« sind auch »sqlite« oder »mysql« möglich. Die Zeilen 10 und 11 geben an, wohin der Dienst seine Logdatei schreiben soll. Es ist auch möglich, den Parameter »log_console« auf »on« zu stellen, damit Dhcpy6d direkt auf Stdout loggt. Zeile 13 ist sehr wichtig, der Admin darf nicht vergessen, den Dienst dort einzuschalten.

Der Block in den Zeilen 15 bis 19 gibt die Parameter für das Eintragen der Clients in einen Nameserver vor. Der letzte Parameter dort bestimmt, dass nicht der vom Client geschickte Hostname zum Zuge kommt, sondern der Hostname aus der »client.conf« -Datei. Die Liste der DNS-Domains, in denen ein Client suchen soll, lässt sich leider nur global und nicht in der Klasse angeben.

Nun folgt die Addressendefinition für die Default-Klasse. Hier ist lediglich ein Netzblock vorgegeben, an den Dhcpy6d hinten die MAC-Adresse anhängt. Neben der Kategorie »mac« sind noch möglich:

• Range, um einen Von-bis-Bereich anzugeben.
• Id, dies setzt voraus, dass der Admin in der Clientdefinition eine ID zugewiesen hat, die er dann hier einsetzt.
• Random, um eine Zufallszahl zu platzieren.

Der zweite Adressenblock in den Zeilen 26 bis 31 legt fest, dass ein DNS-Update stattfinden soll, und es sind die Forward- und Reverse-Zonen spezifiziert. Der Schluss der Datei erledigt die Definition der Klasse Special. Der Eintrag in Zeile 34 muss zu dem Namen des Adressenbereichs passen, auch hier sind mehrere Bereiche möglich. Als einzigen Parameter erwartet diese Klasse die IPv6-Adresse des Nameservers.

Die “client.conf”-Datei

Die Datei »client.conf« enthält die Daten der einzelnen Clients, Listing 2 gibt ein Beispiel mit nur einem Client. In den eckigen Klammern steht der Identifier. Den Hostnamen verwendet Dhcpy6d für den Eintrag in den DNS. Die MAC-Adresse dient der Identifizierung des Clients; hier mehrere Adressen anzugeben ist erlaubt.

01 [testclient]
02 hostname = v6client
03 mac = 02:01:02:03:04:09
04 address = 2001:db8::5555
05 class = special

Der Parameter in Zeile 4 beinhaltet eine Adresse, die der Client zusätzlich zu der Adresse aus dem Pattern im Adressenbereich erhält. Die letzte Zeile schließlich ordnet den Client seiner Klasse zu. Statt der MAC darf der Systemverwalter hier auch eine oder mehrere DUIDs mit dem Parameter »duid« verwenden.

Passen jetzt beide Konfigurationsdateien zum eigenen Setup und läuft der Dhcpy6d auf dem Router, dürfen ein »ifconfig« auf dem Client und eine Ausgabe ähnlich zu Listing 3 den Anstoß zu Erfolgsfeierlichkeiten geben.

01 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
02         inet6 2001:db8::201:203:409  prefixlen 64  scopeid 0x0<global>
03         inet6 2001:db8::5555  prefixlen 64  scopeid 0x0<global>
04         inet6 fe80::1:2ff:fe03:409  prefixlen 64  scopeid 0x20<link>
05         ether 02:01:02:03:04:09  txqueuelen 1000  (Ethernet)

Testergebnis und Fazit

Theoretisch kommt der Admin eines IPv6-Netzes ohne DHCP-Server aus, in größeren Netzen – und darum handelt es sich bei IPv6 meist – praktisch nicht. Da die Auswahl an Tools beschränkt ist, verdient jeder Neuankömmling Beachtung. Dhcpy6d hinterlässt beim Tester einen zwiespältigen Eindruck. Die aus der Praxis geborene Idee, auf den RFC zu pfeifen und trotzdem eine Zuordnung über die MAC-Adresse zuzulassen, erscheint zunächst nicht verkehrt. Wie ein DHCPv6-Dienst die DUIDs in der Praxis errechnet, unterscheidet sich sowieso von Implementierung zu Implementierung.

Was dem Autor allerdings besonders fehlt, ist die Zuordnung nach Netzbereichen. In größeren Netzen werden auch bei IPv6 DHCP-Relay-Agents eingesetzt, und neben der MAC-Adresse kommt es dann beim DHCPv6-Server auch auf die Information an, in welchem Segment der Client liegt, sodass die für das Netz richtigen Parameter vorliegen.

Das realisiert Dhcpy6d nur in Form einzelner Clientdefinitionen und Klassen. Unbekannte Clients in Netzen landen stets in der Default-Klasse, sie erhalten somit falsche Adressen zugewiesen und beispielsweise den falsche DNS-Server. Das kann der Admin nur durch manuelle Einträge in den Griff bekommen, was aber mit jedem Dutzend Clients problematischer wird.

Test verbessert Qualität

Eine Nebenerkenntnis der Tests zu diesem Artikel ist, dass Henri Wahl, der Autor des Software, offenbar einen guten Support bei Rückfragen von Anwendern bietet. Umgekehrt helfen die Fragen auch dem Entwickler: Da die Magazin-Tester durch eine andere Art des Herangehens an die Konfiguration einige logische Lücken aufdeckten, führten die Recherchen sogar zu mehreren Git-Commits.