Zum Hauptinhalt springen

1. Einführung (Introduction)

Das dynamische Host-Konfigurationsprotokoll (Dynamic Host Configuration Protocol, DHCP) stellt Konfigurationsparameter für Internet-Hosts bereit. DHCP besteht aus zwei Komponenten: einem Protokoll zur Übermittlung hostspezifischer Konfigurationsparameter von einem DHCP-Server zu einem Host und einem Mechanismus zur Zuweisung von Netzwerkadressen an Hosts.

DHCP basiert auf einem Client-Server-Modell, bei dem designierte DHCP-Server-Hosts Netzwerkadressen zuweisen und Konfigurationsparameter an dynamisch konfigurierte Hosts übermitteln. Im Rest dieses Dokuments bezieht sich der Begriff „Server" auf einen Host, der Initialisierungsparameter über DHCP bereitstellt, und der Begriff „Client" bezieht sich auf einen Host, der Initialisierungsparameter von einem DHCP-Server anfordert.

Ein Host sollte nicht als DHCP-Server fungieren, es sei denn, er wird explizit von einem Systemadministrator dazu konfiguriert. Die Vielfalt der Hardware- und Protokollimplementierungen im Internet würde einen zuverlässigen Betrieb verhindern, wenn zufällige Hosts auf DHCP-Anfragen antworten dürften. Beispielsweise erfordert IP die Festlegung vieler Parameter in der Protokollimplementierungssoftware. Da IP auf vielen verschiedenen Arten von Netzwerkhardware verwendet werden kann, können die Werte für diese Parameter nicht erraten oder als korrekte Standardwerte angenommen werden. Außerdem hängen verteilte Adresszuweisungsschemata von einem Polling-/Verteidigungsmechanismus zur Erkennung bereits verwendeter Adressen ab. IP-Hosts können möglicherweise nicht immer ihre Netzwerkadressen verteidigen, sodass ein solches verteiltes Adresszuweisungsschema nicht garantieren kann, die Zuweisung doppelter Netzwerkadressen zu vermeiden.

DHCP unterstützt drei Mechanismen zur IP-Adresszuweisung. Bei der „automatischen Zuweisung" weist DHCP einem Client eine permanente IP-Adresse zu. Bei der „dynamischen Zuweisung" weist DHCP einem Client eine IP-Adresse für einen begrenzten Zeitraum zu (oder bis der Client die Adresse explizit freigibt). Bei der „manuellen Zuweisung" wird die IP-Adresse eines Clients vom Netzwerkadministrator zugewiesen, und DHCP wird lediglich verwendet, um die zugewiesene Adresse an den Client zu übermitteln. Ein bestimmtes Netzwerk wird einen oder mehrere dieser Mechanismen verwenden, abhängig von den Richtlinien des Netzwerkadministrators.

Die dynamische Zuweisung ist der einzige dieser Mechanismen, der eine automatische Wiederverwendung einer Adresse ermöglicht, die vom Client, dem sie zugewiesen wurde, nicht mehr benötigt wird. Daher ist die dynamische Zuweisung besonders nützlich für die Zuweisung einer Adresse an einen Client, der nur vorübergehend mit dem Netzwerk verbunden ist, oder für die gemeinsame Nutzung eines begrenzten Pools von IP-Adressen zwischen einer Gruppe von Clients, die keine permanenten IP-Adressen benötigen. Die dynamische Zuweisung kann auch eine gute Wahl für die Zuweisung einer IP-Adresse an einen neuen Client sein, der dauerhaft mit einem Netzwerk verbunden ist, in dem IP-Adressen so knapp sind, dass es wichtig ist, sie zurückzugewinnen, wenn alte Clients ausgemustert werden. Die manuelle Zuweisung ermöglicht die Verwendung von DHCP zur Beseitigung des fehleranfälligen Prozesses der manuellen Konfiguration von Hosts mit IP-Adressen in Umgebungen, in denen es (aus welchen Gründen auch immer) wünschenswert ist, die IP-Adresszuweisung außerhalb der DHCP-Mechanismen zu verwalten.

Das Format der DHCP-Nachrichten basiert auf dem Format der BOOTP-Nachrichten, um das in der BOOTP-Spezifikation [7, 21] beschriebene Verhalten des BOOTP-Relay-Agenten zu erfassen und die Interoperabilität bestehender BOOTP-Clients mit DHCP-Servern zu ermöglichen. Die Verwendung von BOOTP-Relay-Agenten beseitigt die Notwendigkeit, auf jedem physischen Netzwerksegment einen DHCP-Server zu haben.

1.1 Änderungen gegenüber RFC 1541​

Dieses Dokument aktualisiert die DHCP-Protokollspezifikation, die in RFC 1541 erscheint. Ein neuer DHCP-Nachrichtentyp, DHCPINFORM, wurde hinzugefügt; siehe Abschnitte 3.4, 4.3 und 4.4 für Details. Der Klassifizierungsmechanismus zur Identifizierung von DHCP-Clients gegenüber DHCP-Servern wurde erweitert, um „Anbieter"-Klassen einzuschließen, wie in den Abschnitten 4.2 und 4.3 definiert. Die Mindestlaufzeitbeschränkung wurde entfernt. Schließlich wurden viele redaktionelle Änderungen vorgenommen, um den Text aufgrund der bei DHCP-Interoperabilitätstests gewonnenen Erfahrungen zu klären.

1.2 Verwandte Arbeiten​

Es gibt mehrere Internet-Protokolle und verwandte Mechanismen, die einige Teile des Gesamtproblems der Host-Konfiguration adressieren. Das Reverse Address Resolution Protocol (RARP) [10] (durch die im Dynamic RARP (DRARP) [5] definierten Erweiterungen) behandelt explizit das Problem der Netzwerkadresserkennung und umfasst einen automatischen IP-Adresszuweisungsmechanismus. Das Trivial File Transfer Protocol (TFTP) [20] ermöglicht den Transport eines Boot-Images von einem Boot-Server. Das Internet Control Message Protocol (ICMP) [16] informiert Hosts über zusätzliche Router durch „ICMP-Redirect"-Nachrichten. ICMP kann auch Subnetzmaskeninformationen über die „ICMP-Maskenanfrage"-Nachricht und andere Informationen über die (veraltete) „ICMP-Informationsanfrage"-Nachricht bereitstellen. Hosts können Router über den ICMP-Router-Discovery-Mechanismus [8] lokalisieren.

BOOTP ist ein Transportmechanismus für eine Sammlung von Konfigurationsinformationen. BOOTP ist auch erweiterbar, und offizielle Erweiterungen [17] wurden für mehrere Konfigurationsparameter definiert. Morgan hat Erweiterungen für BOOTP zur dynamischen IP-Adresszuweisung vorgeschlagen [15]. Das Network Information Protocol (NIP), das vom Athena-Projekt am MIT verwendet wird, ist ein verteilter Mechanismus zur dynamischen IP-Adresszuweisung [19]. Das Resource Location Protocol RLP [1] ermöglicht die Lokalisierung höherer Dienste. Sun Microsystems plattenlose Workstations verwenden eine Boot-Prozedur, die RARP, TFTP und einen RPC-Mechanismus namens „bootparams" einsetzt, um Konfigurationsinformationen und Betriebssystemcode an plattenlose Hosts zu übermitteln. (Sun Microsystems, Sun Workstation und SunOS sind Marken von Sun Microsystems, Inc.) Einige Sun-Netzwerke verwenden auch DRARP und einen Auto-Installationsmechanismus zur Automatisierung der Konfiguration neuer Hosts in einem bestehenden Netzwerk.

In anderen verwandten Arbeiten kann der Algorithmus zur Pfad-Minimum-Transmission-Unit (MTU)-Erkennung die MTU eines beliebigen Internetpfads bestimmen [14]. Das Address Resolution Protocol (ARP) wurde als Transportprotokoll für die Ressourcenlokalisierung und -auswahl vorgeschlagen [6]. Schließlich erwähnen die Host-Requirements-RFCs [3, 4] spezifische Anforderungen für die Host-Rekonfiguration und schlagen ein Szenario für die Erstkonfiguration von plattenlosen Hosts vor.

1.3 Problemdefinition und Fragestellungen​

DHCP ist darauf ausgelegt, DHCP-Clients die in den Host-Requirements-RFCs definierten Konfigurationsparameter bereitzustellen. Nach Erhalt von Parametern über DHCP sollte ein DHCP-Client in der Lage sein, Pakete mit jedem anderen Host im Internet auszutauschen. Die von DHCP bereitgestellten TCP/IP-Stack-Parameter sind in Anhang A aufgeführt.

Nicht alle diese Parameter sind für einen neu initialisierten Client erforderlich. Ein Client und ein Server können über die Übertragung nur der vom Client benötigten oder für ein bestimmtes Subnetz spezifischen Parameter verhandeln.

DHCP erlaubt, erfordert aber nicht die Konfiguration von Client-Parametern, die nicht direkt mit dem IP-Protokoll zusammenhängen. DHCP behandelt auch nicht die Registrierung neu konfigurierter Clients im Domain Name System (DNS) [12, 13].

DHCP ist nicht für die Konfiguration von Routern vorgesehen.

1.4 Anforderungen​

Im gesamten Dokument werden die Wörter, die zur Definition der Bedeutung bestimmter Anforderungen verwendet werden, groß geschrieben. Diese Wörter sind:

"MUST" (muss)​

Dieses Wort oder das Adjektiv „REQUIRED" bedeutet, dass der Punkt eine absolute Anforderung dieser Spezifikation ist.

"MUST NOT" (darf nicht)​

Diese Phrase bedeutet, dass der Punkt ein absolutes Verbot dieser Spezifikation ist.

"SHOULD" (sollte)​

Dieses Wort oder das Adjektiv „RECOMMENDED" bedeutet, dass es unter bestimmten Umständen triftige Gründe geben kann, diesen Punkt zu ignorieren, aber die vollständigen Auswirkungen sollten verstanden und der Fall sorgfältig abgewogen werden, bevor eine andere Vorgehensweise gewählt wird.

"SHOULD NOT" (sollte nicht)​

Diese Phrase bedeutet, dass es unter bestimmten Umständen triftige Gründe geben kann, bei denen das aufgeführte Verhalten akzeptabel oder sogar nützlich ist, aber die vollständigen Auswirkungen sollten verstanden und der Fall sorgfältig abgewogen werden, bevor ein mit diesem Label beschriebenes Verhalten implementiert wird.

"MAY" (kann)​

Dieses Wort oder das Adjektiv „OPTIONAL" bedeutet, dass dieser Punkt wirklich optional ist. Ein Anbieter kann sich dafür entscheiden, den Punkt einzuschließen, weil ein bestimmter Markt ihn erfordert oder weil er das Produkt verbessert, zum Beispiel; ein anderer Anbieter kann denselben Punkt weglassen.

1.5 Terminologie​

Dieses Dokument verwendet die folgenden Begriffe:

"DHCP client" (DHCP-Client)​

Ein DHCP-Client ist ein Internet-Host, der DHCP verwendet, um Konfigurationsparameter wie eine Netzwerkadresse zu erhalten.

"DHCP server" (DHCP-Server)​

Ein DHCP-Server ist ein Internet-Host, der Konfigurationsparameter an DHCP-Clients zurückgibt.

"BOOTP relay agent" (BOOTP-Relay-Agent)​

Ein BOOTP-Relay-Agent oder Relay-Agent ist ein Internet-Host oder Router, der DHCP-Nachrichten zwischen DHCP-Clients und DHCP-Servern weiterleitet. DHCP ist so konzipiert, dass es das gleiche Relay-Agent-Verhalten verwendet, wie es in der BOOTP-Protokollspezifikation dokumentiert ist.

"binding" (Bindung)​

Eine Bindung ist eine Sammlung von Konfigurationsparametern, einschließlich mindestens einer IP-Adresse, die mit einem DHCP-Client verknüpft oder an diesen „gebunden" ist. Bindungen werden von DHCP-Servern verwaltet.

1.6 Designziele​

Die folgende Liste gibt allgemeine Designziele für DHCP an.

  • DHCP sollte ein Mechanismus und keine Richtlinie sein. DHCP muss lokalen Systemadministratoren die Kontrolle über Konfigurationsparameter ermöglichen, wo gewünscht; zum Beispiel sollten lokale Systemadministratoren in der Lage sein, lokale Richtlinien bezüglich der Zuweisung und des Zugriffs auf lokale Ressourcen durchzusetzen, wo gewünscht.

  • Clients sollten keine manuelle Konfiguration erfordern. Jeder Client sollte in der Lage sein, geeignete lokale Konfigurationsparameter ohne Benutzereingriff zu entdecken und diese Parameter in seine eigene Konfiguration zu integrieren.

  • Netzwerke sollten keine manuelle Konfiguration für einzelne Clients erfordern. Unter normalen Umständen sollte der Netzwerkmanager keine clientspezifischen Konfigurationsparameter eingeben müssen.

  • DHCP sollte keinen Server auf jedem Subnetz erfordern. Um Skalierung und Wirtschaftlichkeit zu ermöglichen, muss DHCP über Router oder durch die Intervention von DHCP-Relay-Agenten funktionieren.

  • Ein DHCP-Client muss darauf vorbereitet sein, mehrere Antworten auf eine Anfrage nach Konfigurationsparametern zu erhalten. Einige Installationen können mehrere überlappende DHCP-Server enthalten, um die Zuverlässigkeit zu erhöhen und die Leistung zu steigern.

  • DHCP muss mit statisch konfigurierten, nicht teilnehmenden Hosts und mit bestehenden Netzwerkprotokollimplementierungen koexistieren.

  • DHCP muss mit dem BOOTP-Relay-Agent-Verhalten interoperieren, wie es in RFC 951 und RFC 1542 [21] beschrieben ist.

  • DHCP muss Dienste für bestehende BOOTP-Clients bereitstellen.

Die folgende Liste gibt Designziele an, die spezifisch für die Übertragung der Netzwerkschichtparameter sind. DHCP muss:

  • Garantieren, dass eine bestimmte Netzwerkadresse nicht gleichzeitig von mehr als einem DHCP-Client verwendet wird,

  • Die DHCP-Client-Konfiguration über DHCP-Client-Neustarts hinweg beibehalten. Ein DHCP-Client sollte, wann immer möglich, als Antwort auf jede Anfrage dieselben Konfigurationsparameter (z. B. Netzwerkadresse) zugewiesen bekommen,

  • Die DHCP-Client-Konfiguration über Server-Neustarts hinweg beibehalten, und wann immer möglich sollte einem DHCP-Client trotz Neustarts des DHCP-Mechanismus dieselben Konfigurationsparameter zugewiesen werden,

  • Die automatische Zuweisung von Konfigurationsparametern an neue Clients ermöglichen, um eine manuelle Konfiguration neuer Clients zu vermeiden,

  • Die feste oder permanente Zuweisung von Konfigurationsparametern an bestimmte Clients unterstützen.

Letztes Update am