Andreas Taudte 05. Mai 2014

DHCPv6 Ausfallsicherheit

Eine DHCP Failover Association erlaubt eine Ausfallsicherheit des Dienstes über Netzwerkgrenzen hinaus. © Alkmene Verlags- und Mediengesellschaft mbH

Die Dienste DHCP und DNS werden nicht ohne Grund als Core Network Services (Netzwerkkerndienste) bezeichnet. Ob mittelständischer Familienbetrieb oder Großkonzern – ohne diese rudimentären Dienste kann kein Unternehmensnetzwerk funktionieren. Speziell im Zeitalter von computergesteuerten Fertigungsanlagen, Smart Metering und IP-basierter Gebäudeüberwachung gewinnen DNS und DHCP noch mehr an Bedeutung. Aber auch ein stetiges Wachstum der IP-fähigen Systeme im Netz und deren steigende Mobilität machen Netzwerkkerndienste unabdingbar.

DHCPv4 Failover

Abb.1: Stetige Kommunikation der beiden Systeme. © Andreas Taudte

Ein bewehrtes Mittel, die Verfügbarkeit des DHCP-Dienstes in einer IPv4-Umgebung zu erhöhen, ist der Aufbau einer sogenannten „Failover Association“. Im von der Internet Engineering Task Force (IETF) beschriebenen Entwurf „draft-ietf-dhc-failover-12“ [1] handelt es sich um eine Protokoll-basierte Geo-Redundanz zwischen zwei aktiven DHCP-Servern. Die geographische Trennung bezieht sich hierbei auf die dritte Schicht des OSI-Modells (Netzwerkschicht) [2]. Eine DHCP Failover Association erlaubt damit eine Ausfallsicherheit des Dienstes über Netzwerkgrenzen hinaus.

Technisch handelt es sich um zwei DHCP-Server in unterschiedlichen IP-Netzen, die für den gleichen dynamischen Adressraum zuständig sind. Eine stetige Kommunikation der beiden Systeme erlaubt es dem verbleibenden DHCP-Server, im Fehlerfall den Adressraum des anderen zu übernehmen (vgl. Abb. 1).

DHCPv6 Failover

Ebenso wie in der IPv4-Welt handelt es sich bei DHCPv6 Failover um einen IETF Entwurf (draft-ietf-dhc-dhcpv6-failover-design-04, [3]), der im März 2014 auslief. Zum Zeitpunkt der Erstellung dieses Artikels verfügten die beiden den Markt beherrschenden Systeme Microsoft DHCP [4] und ISC DHCP [5] über keine Implementierung des IEFT Entwurfs für DHCPv6 Failover. Nach einer Präsentation zu diesem Thema auf Deutschlands einschlägiger IPv6-Konferenz wurde darüber diskutiert, dass es nicht-kommerzielle Entwicklungen in dieser Richtung gibt, die aber nur für den Eigenbedarf verfügbar seien. Dies bedeutet jedoch nicht, dass keine Redundanz des DHCP-Dienstes unter IPv6 möglich ist. Der „Request for Comments“ (RFC) mit der Nummer 6853 betrachtet mögliche Ansätze, die mit verfügbaren Implementierungen umgesetzt werden können.

Betrachtung der heute verfügbaren Redundanz von DHCPv6

Abb.2: Beteiligte Systeme und deren Kommunikation. © Andreas Taudte

Mit dem RFC 6853 „DHCPv6 Redundancy Deployment Considerations“ [6] beschreibt die IETF drei semi-redundante Modelle, um die Ausfallsicherheit eines DHCPv6-Dienstes mit heutigen Mitteln zu realisieren.

Voraussetzungen der Modelle

Zunächst sind verschiedene Rahmenbedingungen bezüglich der beteiligten Systeme und deren Kommunikation untereinander zu klären (vgl. Abb. 2).

Zwei oder mehr Server stellen DHCPv6-Dienste für die gleiche Gruppe von Clients bereit.
Die Implementierung aller beteiligten DHCP-Server folgt strikt dem RFC 3315 „Dynamic Host Configuration Protocol for IPv6“ [7].
Die Implementierung aller beteiligten DHCP-Relays (ugs. IP-Helper) folgt ebenfalls strickt dem RFC 3315.
Es gibt keine direkte Kommunikation zwischen den beteiligten DHCP- Servern.
Die von den DHCP-Servern bedienten Clients nutzen „stateful DHCPv6“.
Die von den DHCP-Servern bedienten Clients müssen die sog. „Preference Option“, die im DHCP-Paket enthalten ist, verarbeiten.

Getrennte DHCP-Bereiche

Abb.3: Priorisierung des Servers für den Client. © Andreas Taudte

Im Modell der „Split Scopes“ werden eindeutige, sich nicht überlappende DHCPv6-Bereiche für das gleiche Netzwerk definiert. Die DHCP-Pools sind parallel aktiv, senden aber unterschiedliche Werte in ihrer „Preference Option“. Dies ist eine Art Priorisierung des Servers für den Client (vgl. Abb. 3).

Mehrere, eindeutige DHCP-Bereiche

Abb.4: Konfiguration der DHCPv6-Server mit unterschiedlichen Priorisierungen. © Andreas Taudte

Die Verteilung mehrerer IPv6-Präfixe ist das Prinzip des „Multiple Unique Prefixes”- Modells. Hierbei wird der verfügbare DHCP-Bereich nicht zwischen einer beliebigen Anzahl DHCP-Servern aufgeteilt. Jedes System nutzt seinen eigenen Adressbereich. Wie auch beim Modell der „Split Scopes“ werden die DHCPv6-Server mit unterschiedlichen Priorisierungen konfiguriert (vgl. Abb. 4).

Identische DHCP-Bereiche

Abb.5: Wahrscheinlichkeit von Adresskonflikten. © Andreas Taudte

Das Modell der „Identical Prefixes“ basiert auf dem Prinzip der Wahrscheinlichkeit. Alle beteiligten DHCP-Server bieten hierbei dynamische Adressen aus identischen DHCP-Pools des gleichen Netzsegments an. Da der Adressraum bei IPv6 im Vergleich zu IPv4 viel umfangreicher ist, ist die Wahrscheinlichkeit von Adresskonflikten verhältnismäßig gering und akzeptabel (vgl. Abb. 5).

Bewertung der drei Modelle

Alle drei zuvor beschriebenen Modelle scheinen das Problem der fehlenden Ausfallsicherheit eines DHCPv6-Servers lösen zu können. Allerdings ergeben sich durch die verschieden Ansätze unterschiedliche Vor- und Nachteile.

Die Aufteilung der verfügbaren DHCP-Adressen auf zwei (oder mehrere) Systeme ist ein bekanntes Prinzip in IPv4-Netzwerken. Ein erheblicher Nachteil entsteht bei dieser Methode durch den Verlust eines Systems. Hierdurch reduziert sich die Anzahl der verfügbaren Adressen drastisch. In IPv4-Netzen kann es zum Ausfall des Dienstes kommen, wenn der DHCP-Bereich des bleibenden Systems nicht ausreichend Adressen für alle Clients bietet. In IPv6-Netzen kann dieses Risiko stark reduziert werden, indem die aufgeteilten Adressbereiche hinreichend groß dimensioniert werden. Von einer Verschwendung der Adressen, wie sie bei diesem Szenario unter IPv4 bekannt ist, muss unter IPv6 nicht ausgegangen werden. Die allgemein empfohlene Größe von 64bit im Hostanteil der Netzwerkadresse erlaubt einen sehr großzügigen Umgang mit DHCP-Bereichen. Das tatsächliche Problem beim „Split Scopes“-Modell liegt in der Administrierbarkeit – speziell bei mehreren DHCPv6-Serverpaaren. Ohne ein geeignetes Verwaltungswerkzeug können sich rasch Fehlkonfigurationen einschleichen, die unter Umständen zum Verlust des Dienstes führen können.

Das „Multiple Unique Prefixes”-Modell hingegen weist jedem DHCPv6-Server ein eindeutiges Netzwerk mit eindeutigem, dynamischen Pool zu. Ähnlich wie beim zuvor beschriebenen Ansatz sind lediglich die DHCP-Bereiche innerhalb der 64er-Netzwerke hinreichend groß zu wählen, um nicht in die Verlegenheit der Adressknappheit zu geraten. Die Komplexität bei der Administration ist wesentlich geringer als bei der „Split Scopes“-Methode. Es kann hier leicht mit Templates gearbeitet werden. Zu berücksichtigen ist jedoch, dass mehrere IPv6-Präfixe im gleichen Netzwerksegment verteilt werden. Unter IPv4 ist dieses Verfahren als „Superscoping“ bekannt. Dies beeinflusst wiederum die Definition von „Access Control Lists“ (ACL) und deren Verwaltung.

Die Verwaltbarkeit der „Identical Prefixes“-Methode gestaltet sich simpel, da jedes DHCP-System die identische Konfiguration erhält. Ein Mangel an verfügbaren, dynamischen Adressen kann im Falle eines Defekts eines der Systeme nicht eintreten. Unter der Voraussetzung, dass die DHCP-Adressen den Clients zufällig als Lease angeboten werden, ist die Wahrscheinlichkeit einer Doppelbelegung bei der Adressvergabe äußerst gering. Die Praxis zeigt jedoch, dass die aktuellen DHCPv6-Implementierungen einen dynamischen Pool oft nach dem gleichen Prinzip füllen, z. B. beginnend mit der letzten verfügfahren Adresse des Bereichs. Dadurch kommt es durchaus zu Adresskonflikten.

Zusammenfassend lässt sich feststellen, dass alle drei Modelle eher eine Übergangslösung als ein tatsächlicher Ansatz für die Ausfallsicherheit einer DHCPv6-Umgebung sind. Zum Einen berücksichtigt keines der Modelle Vorkehrungen für den Fall, dass ein ausgefallenes System wieder aktiv Adressen bereitstellt. Zum Anderen ergibt sich bei manchen Modellen die Möglichkeit von Überschneidungen bei der Adressvergabe – auch wenn die Wahrscheinlichkeit gering ist.

Des Weiteren muss die dynamische Aktualisierung von DNS-Einträgen durch die DHCP-Server betrachtet werden. Dieses Prinzip ist üblich in IPv4 und wurde auch für IPv6 übernommen. Es kann zu Unstimmigkeiten im dynamischen DNS (DDNS) kommen, wenn mehrere DHCP-Server identisch konfiguriert sind. Das Problem besteht ebenfalls, wenn DHCPv4- und DHCPv6-Server gleichzeitig die selbe DNS-Zone aktualisieren. Speziell beim ISC DHCP hilft an dieser Stelle die „update-conflict-detection“-Anweisung.

Warum es (noch) kein DHCPv6-Failover gibt

Nachdem zwei Server eine Failover Association aufgebaut haben, werden die Adressen des Pools aufgeteilt. RFC 3074 beschreibt den „DHC Load Balancing Algorithm“, der vom ISC im DHCP-Daemon implementiert ist. Standardmäßig wird ein DHCP-Pool zwischen zwei „Peers“ zu 50/50 aufgeteilt (aktiv-aktiv-Modus).

Dieses Konstrukt weist jedoch in der Praxis seine Tücken auf. Speziell das sog. „Rebalancing“ kann zu einem unerwarteten Verhalten im DHCP führen. Dieser Abgleich der verfügbaren IP-Adressen erfolgt regelmäßig für jeden einzelnen DHCP-Pool, für den Failover aktiv ist.

Sep 1 10:31:04 b0ad00ac5n dhcpd:     DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
                                     192.168.0.1: peer holds all free leases
Sep 1 10:31:07 b0ad00ac5n dhcpd:     balancing pool b3f5ed0 192.168.0.0/19
                                     total 8189 free 8143 backup 0 lts -4071
                                     max-own (+/-)814 (requesting peer
                                     rebalance!)

Hierbei wird allerdings nicht das Delta übertragen, sondern eine Liste aller freien und belegten Adressen. Abgelegt werden die Details im sog. „Leases File“ (dhcpd.leases).

[...]
lease 192.168.0.240 {
  binding state free;
}
[...]

In Umgebungen mit vielen Failover-Pools und besonders bei großen Netzen beeinträchtigt das Rebalancing den DHCP-Dienst erheblich. In der Regel wird mit DHCP-Failover eine geographische Redundanz erzielt, wodurch die Kombination aus Rebalancing und Latenzzeit zu berücksichtigen ist. Aus dem Projekt einer international tätigen Finanzdienstleistungsgesellschaft ist bekannt, dass zwei geographisch nicht (!) getrennte DHCP-Server im Failover-Modus konfiguriert für 500.000 Clients etwa 3 Minuten für die Synchronisation ihrer Leases benötigen. Hier kann von einer Latenzzeit gegen Null ausgegangen werden. Würde man die Systeme auf dem Campus verteilen, ist eine Latenzzeit von 55ms anzunehmen. In diesem Fall ist mit einer Synchronisationsdauer von bis zu 45 min. zu rechnen. Dies kann die Vergabe von IP-Adressen durch den DHCP-Dienst stark beeinträchtigen.

Betrachtet man nun die immense Masse der IP-Adressen eines IPv6-Netzwerks und des darin enthaltenen Pools, wird klar, dass der bisher genutzte Rebalancing-Algorithmus den DHCP-Dienst rasch zum Erliegen bringen kann.

Referenzen

Titel	Referenz
DHCPv6 Redundancy Considerations	s. Quelle [8]
DHC Load Balancing Algorithm	RFC 3074
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)	RFC 3315
IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6	RFC 3633
A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)	RFC 4701
Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients	RFC 4703
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option	RFC 4704
DHCPv6 Leasequery	RFC 5007
DHCPv6 Bulk Leasequery	RFC 5460
DHCPv6 Options for Network Boot	RFC 5970
DHCPv6 Redundancy Considerations	RFC 6853