Proseminar DHCP - Informatik 4
Proseminar DHCP - Informatik 4
Proseminar DHCP - Informatik 4
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Rheinisch-Westfälische Technische Hochschule Aachen<br />
Lehrstuhl für <strong>Informatik</strong> IV<br />
Prof. Dr. rer. nat. Otto Spaniol<br />
Dynamic Host Configuration Protocol<br />
<strong>Proseminar</strong>: Dynamic Host Configuration<br />
Protocol<br />
WS 2002/2003<br />
Nils Gräf<br />
Matrikelnummer: 232827<br />
Betreuung: Mesut Günes<br />
Lehrstuhl für <strong>Informatik</strong> IV, RWTH Aachen
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
Inhaltsverzeichnis<br />
1. Einführung .................................................................................................................. 2<br />
1.1 Erklärung der Fachbegriffe .................................................................................. 2<br />
2. BOOTP........................................................................................................................ 4<br />
3. <strong>DHCP</strong>........................................................................................................................... 5<br />
3.1 Aufbau eines <strong>DHCP</strong>-Pakets ................................................................................. 6<br />
3.2 Arten der Anfragen............................................................................................... 7<br />
3.3 Ablauf einer Zuordnung....................................................................................... 8<br />
3.4 Leasezeiten........................................................................................................... 9<br />
3.5 <strong>DHCP</strong>-Relay....................................................................................................... 11<br />
4. Praktisches Beispiel.................................................................................................. 13<br />
4.1 Konfigurationsdatei............................................................................................ 14<br />
4.2 Manuelle Zuordnung.......................................................................................... 15<br />
4.3 Automatische Zuordnung................................................................................... 16<br />
4.4 Dynamische Zuordnung..................................................................................... 16<br />
5. Zusammenfassung .................................................................................................... 17<br />
6. Quellenangabe .......................................................................................................... 18<br />
1
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
1. Einführung<br />
Diese Ausarbeitung soll dem Leser das Dynamic Host Configuration Protocol näher<br />
bringen. Was ist das <strong>DHCP</strong> und warum wurde es entwickelt Diese beiden Fragen sind die<br />
Hauptaspekte, worauf diese Arbeit eingeht. Die Motivation, die hinter diesem Protokoll steht,<br />
ist schnell beschrieben und leicht verständlich. Man stelle sich ein großes<br />
Softwareunternehmen mit mehreren tausend Rechnern vor. Dieses Netzwerk muss<br />
administriert und gut strukturiert sein. In der Zeit vor <strong>DHCP</strong> musste, sobald etwas<br />
Gravierendes im Netzwerk verändert wurde, zum Beispiel ein neuer Gateway wurde in<br />
Betrieb genommen, ein Administrator an jeden einzelnen Rechner und die Konfiguration<br />
geändert werden. In solch einem großen Unternehmen werden fast täglich neue PC´s in<br />
Betrieb genommen und andere ausgetauscht. Auch hier musste jedes Mal ein Administrator<br />
die Netzwerkeinstellungen konfigurieren. Bei so vielen Rechnern wird logischerweise auch<br />
eine Unmenge von IP-Adressen benötigt. Diese sind aber im Zeitalter von IPv4 knapp. Dieses<br />
<strong>Proseminar</strong> soll dem Leser verdeutlichen, wie mit <strong>DHCP</strong> diese Probleme gelöst werden. Dazu<br />
wird erst das Prinzip von BOOTP, dem Vorgänger von <strong>DHCP</strong>, erläutert, um dann die Vorteile<br />
von <strong>DHCP</strong> aufzudecken. Anhand von Grafiken wird dann auf den zeitlichen Ablauf einer<br />
<strong>DHCP</strong>-Anfrage eingegangen und aufgezeigt, aus was ein einzelnes Paket besteht.<br />
Abgerundet wird diese Ausarbeitung dann mit einem Beispiel aus der Praxis. Gezeigt wird<br />
eine lauffähige Konfiguration, wie sie unter SuSE Linux 8.0 an einer Schule zum Einsatz<br />
kommt. Darin werden die drei verschiedenen Vergabemodi verwendet und dazu erklärt,<br />
warum der Administrator den jeweiligen Modus gewählt hat und welche Vorteile sich daraus<br />
für die Administration dieses LANs ergeben. Um diese Ausarbeitung besser verstehen zu<br />
können, steht am Anfang eine Erklärung der Fachbegriffe, die nicht als bekannt vorausgesetzt<br />
werden können.<br />
1.1 Erklärung der Fachbegriffe<br />
Address Resolution Protokoll (ARP)<br />
Das ARP setzt eine logische Netzwerkadresse in eine Hardwareadresse um. In Netzwerken<br />
werden die physikalischen Adressen der Rechner nicht verwendet, sondern es handelt sich um<br />
eine logische Adressierung. In TCP/IP-Netzwerken handelt es sich zum Beispiel um das IP-<br />
Adresskonzept.<br />
Broadcast<br />
Wenn eine Nachricht an die Broadcast-Adresse gesendet wird, empfängt jeder angeschlossene<br />
Rechner im Netzwerk diese Nachricht.<br />
Domain Name System (DNS)<br />
Alle Rechner in einem TCP/IP-Netz werden über eine eindeutige IP-Adresse identifiziert.<br />
Diese 4 Byte lange Zahl ist kompliziert und anfällig für Tippfehler. Aus diesem Grund wurde<br />
bereits 1984 das Domain Name System (DNS) geschaffen. Es ermöglicht, Hosts über den<br />
zugehörigen Domainnamen, etwa rwth-aachen.de, zu erreichen. Das DNS ist eine verteilte<br />
Datenbank, deren zentrale Komponenten die Nameserver sind.<br />
2
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
Hardwareadresse<br />
Jeder Netzwerkadapter bekommt bei der Herstellung eine 6 Byte lange Adresse (zumeist in<br />
hexadezimal angegeben) eingebrannt. Diese ist aufgrund von Herstellerabsprachen weltweit<br />
einmalig. Jeder Rechner ist also über diese Adresse eindeutig zu identifizieren.<br />
IPv4/IPv6<br />
Der Unterschied dieser beiden Konzepte liegt hauptsächlich in der Länge der IP-Adresse. Im<br />
alten und derzeit noch verwendeten Standard IPv4 hat eine Adresse die Länge von 4 Byte.<br />
Eine Beispieladresse ist zum Beispiel die 192.168.0.5. Aufgrund der relativ geringen Anzahl<br />
von diesen Adressen ist man nun dabei auf IPv6 zu migrieren. Bei IPv6 ist eine Adresse 16<br />
Byte lang.<br />
Network Information System (NIS)<br />
Das Network Information System ist ein Verzeichnisdienst, der die Benutzung bestimmter<br />
Konfigurationsdateien von verschiedenen Rechnern aus ermöglicht. Insbesondere in<br />
Verbindung mit dem Network File System (NFS) wird NIS verwendet, um Benutzern<br />
netzwerkweit dieselbe Umgebung zur Verfügung zu stellen.<br />
Request For Comment (RFC)<br />
Hierbei handelt es sich um eine fortlaufend durchnummerierte Dokumentensammlung, die<br />
unter Verwaltung des Internet Architecture Board (IAB) steht. Die bestehenden Protokolle<br />
werden gemäß ihres Entwicklungsstandes und Einsatzbereiches kategorisiert. Die RFC´s sind<br />
für die Entwicklung und Bewertung von Protokollen im Internet verantwortlich.<br />
Windows Internet Name Service (WINS)<br />
Vergleichbar mit dem Verfahren, das bei DNS verwendet wird, um IP-Adressen in leichter<br />
lesbarere Namen umzusetzen, stellt WINS eine Methode auf Windows-NT basierten<br />
Systemen dafür zur Verfügung. Der Hauptunterschied zwischen WINS und DNS liegt darin,<br />
dass DNS eine hierarchische Anordnung zur Verfügung stellt (die Namen können in einer<br />
baumartigen Struktur angeordnet werden). WINS stellt einen "flachen" Namensraum zur<br />
Verfügung.<br />
WINS unterscheidet sich vom Standard DNS in drei signifikanten Punkten:<br />
1. WINS ist dynamisch. Wenn ein Microsoft-basierter Computer im Netzwerk<br />
hochgefahren wird, sendet er einen Broadcast an alle physikalisch an diesem Segment<br />
angeschlossenen Systeme. Dies ist ein dynamischer Prozess, bei dem Computer das<br />
Netzwerk betreten und wieder verlassen ohne dass eine Intervention notwendig ist.<br />
Bei DNS werden die IP-Mappings in einer Datenbank gehalten, die jemand<br />
administrieren muss. DNS stellt Anfragen über einen Requestor namens BIND,<br />
während NetBIOS über Broadcasts oder gerichtete Datagramme an den WINS-Server<br />
anfragt.<br />
2. Ein NetBIOS Name kann nicht ohne zusätzliche Software über DNS aufgelöst<br />
werden. Microsofts DNS-Server integriert sich in seinen WINS-Service, der DNS<br />
sagt, dass er WINS als eine Art 'hosts'-Datei behandeln soll.<br />
3. Bei NetBIOS müssen Namen im ganzen Netzwerk eindeutig sein, während bei DNS<br />
mehrfache Namen (sogar in derselben Domäne) zulässig sind.<br />
3
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
2. BOOTP – Bootstrap Protocol<br />
Das Kapitel 2 ist frei nach dem Buch TCP/IP-Grundlagen von Gerhard Lienemann [3]<br />
verfasst. Es ist nur auf die nötigen Bedürfnisse zu dem eigentlichen Thema gekürzt und die<br />
Thematik sprachlich angepasst.<br />
Das BOOTP-Protokoll ist ausschließlich dazu entwickelt worden, um Boot-Vorgänge von<br />
Diskless-Workstations, also von Rechnern ohne Disketten- und Festplattenlaufwerk, zu<br />
realisieren.<br />
Mit BOOTP wird nicht das eigentliche Netzwerk-Booten sondern lediglich die Übernahme<br />
der relevanten Netzwerkdaten (z. B. der eigenen IP-Adresse) bewerkstelligt. Der Ladevorgang<br />
selber wird dann von herkömmlichen Transferprotokollen wie TFTP (Trivial File Transfer<br />
Protocol) übernommen.<br />
Der BOOTP-Client beginnt den Bootvorgang mit einem IP-Broadcast, womit er seine<br />
Hardwareadresse dem Server übermittelt. Derjenige Bootserver, dem diese Adresse „bekannt“<br />
ist, antwortet und schickt ihm seine IP-Adresse, den Namen vom Bootserver und den Namen<br />
des Bootfiles, welches geladen werden soll. Nach dem Ladevorgang des Bootfiles und dem<br />
Booten ist dieser Rechner ein vollwertiges Mitglied des Netzwerkes.<br />
Nach dem RFC 951 [1] kann man die Aktivitäten eines BOOTP-Clients folgendermaßen<br />
charakterisieren:<br />
Wie lautet mein Name<br />
Die Hardwareadresse ist in einem Netzwerk letztlich für die physikalische Adressierung<br />
verantwortlich. Diese ist in der Regel auf dem ROM der Netzwerkkomponente eingebrannt,<br />
ist im Netzwerk eindeutig und wird durch einen separaten BOOTP-Vorgang vor dem<br />
Bootvorgang ausgelesen.<br />
Wie erreiche ich volle Netzwerkfähigkeit<br />
Die Frage „Wer kennt mich“ stellt der BOOTP-Client netzwerkweit mit einem BootP-<br />
Request. Die bereits ausgelesene Hardwareadresse ist Teil dieses Requests, wodurch der für<br />
diesen Client verantwortliche Server seinen „Kunden“ eindeutig erkennt und ihm einen Reply<br />
sendet. Dieser Reply enthält die eigene IP-Adresse, die IP-Adresse des Servers, den Namen<br />
des Bootfiles und gegebenenfalls auch noch die IP-Adresse eines Routers. Mit dieser Basis-<br />
Konfiguration lassen sich nun auch ARP-Requests und -Replies bearbeiten, und das TFT-<br />
Protokoll kann zur Übertragung des Bootfiles verwendet werden.<br />
Wie erhalte ich die erforderliche „Kommunikations-Intelligenz“<br />
Da nun alle notwendigen Informationen für den „remote“-Bootvorgang vorliegen, kann dieser<br />
über TFTP vorgenommen werden. Während des Ladevorganges erfolgt auch die Übernahme<br />
weiterer Netzwerkinformationen. Der Client wird initialisiert, und nach der Etablierung der<br />
Netzwerkverbindungen ist der Client einsatzbereit.<br />
4
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
3. <strong>DHCP</strong> – Dynamic Host Configuration Protocol<br />
Die Möglichkeiten von BOOTP stießen schnell an ihre Grenzen, und auf Grund der<br />
technischen Entwicklung kamen neue Probleme auf. Ein Netzwerk ist lange nicht mehr so<br />
statisch wie es früher einmal war. Wie oft kommt es vor, dass z.B. auf einer Tagung jemand<br />
mit einem Notebook kommt und sich „mal eben“ in das Intranet einloggen will Soll dazu<br />
jedes Mal der Administrator gerufen werden, um die richtige Konfiguration des Clients<br />
vorzunehmen In großen Unternehmen trat mit der Zeit aber auch ein anderes Problem auf.<br />
Die IP-Adressen wurden knapp. Jeder PC hatte seine eigene IP-Adresse, aber nie waren alle<br />
Rechner im Einsatz, und einige IP-Adressen lagen die meiste Zeit brach. Diese beiden<br />
Probleme waren die Hauptmotivation, um BOOTP weiterzuentwickeln. Das Ergebnis ist<br />
<strong>DHCP</strong>. Alle Funktionen von BOOTP wurden übernommen, dieselben Ports, verwendet und<br />
jeder BOOTP-Client kann mit einem <strong>DHCP</strong>-Server kommunizieren. <strong>DHCP</strong> ist nicht nur für<br />
Diskless-Workstations gedacht, sondern soll allgemein die Netzwerkkonfigurationen der<br />
Clients zentralisieren, und damit sind diese viel leichter zu administrieren. Außerdem kann<br />
<strong>DHCP</strong> die ihm zur Verfügung stehenden IP-Adressen dynamisch vergeben, so dass wirklich<br />
immer nur so viele IP-Adressen vergeben sind wie es aktive PC´s im Netzwerk gibt.<br />
Insgesamt gibt es drei verschiedene Arten wie das Dynamic Host Configuration Protocol<br />
seine Clients bedienen kann. Auf diese Varianten mit ihren Vor- und Nachteilen wird in<br />
Kapitel 4 anhand eines praktischen Beispiels eingegangen. <strong>DHCP</strong> ist in dem RFC 2131 [4]<br />
festgelegt. Es gibt einige weitere RFC´s, die das Verhalten von diesem Protokoll beschreiben,<br />
wie das RFC 2132 [5]. Ein Weiteres, welches erwähnt werden sollte, ist das RFC 1534 [2],<br />
welches die Interaktion zwischen BOOTP und <strong>DHCP</strong> beschreibt. Das Dynamic Host<br />
Configuration Protocol ist nur in TCP/IP-Netzwerken implementiert und dafür optimiert. Ein<br />
Einsatz in nicht IP-basierten Netzen, wie zum Beispiel Novell Netware-Netzwerke, ist aber<br />
auch gar nicht sinnvoll, da ja eine der Hauptaufgaben von <strong>DHCP</strong> das dynamische Verwalten<br />
von eben diesen IP-Adressen ist.<br />
<strong>DHCP</strong> ist aber wohl auch einer der Hauptgründe, warum IPv6 sich noch bis heute nicht weiter<br />
durchsetzen konnte. Denn die durch das große Wachstum des Internet knapp werdenden<br />
IPv4-Adressen werden nun effektiver verwendet, und ein Umstieg auf ein neues System mit<br />
mehr Adressen ist so nicht mehr ganz so dringend. Stellen Sie sich nur mal vor, es gäbe kein<br />
<strong>DHCP</strong> und jeder private PC, der mit dem Internet verbunden ist, hätte eine eigene Adresse.<br />
Leicht vorstellbar, dass da die 4 Milliarden möglichen Adressen schnell verbraucht wären.<br />
Dem Internet stehen aber ungefähr nur die Hälfte dieser Adressen zur Verfügung, da aufgrund<br />
von großen Firmen, denen Class A-Netze gehören, einige Adressen vergeben sind, aber<br />
niemals im wirklichen Gebrauch sein werden.<br />
Nach dieser Motivation wird nun die technische Umsetzung dargestellt. Begonnen wird im<br />
nächsten Abschnitt mit dem Aufbau einer einzelnen <strong>DHCP</strong>-Nachricht.<br />
5
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
3.1 Aufbau eines <strong>DHCP</strong>-Pakets<br />
In diesem Abschnitt soll der Aufbau eines einzelnen <strong>DHCP</strong>-Message-Paketes verdeutlicht<br />
werden. Die Zahlen in den Klammern geben die Länge des jeweiligen Feldes in Bytes an.<br />
Erläuterung der einzelnen Felder:<br />
Fig. 1: Aufbau eines <strong>DHCP</strong>-Pakets<br />
Name<br />
Bytes Erklärung<br />
Op 1 Typ der Nachricht<br />
Htype 1 Art der Hardwareadresse<br />
Hlen 1 Länge der Hardwareadresse<br />
Hops 1 Anzahl der zu überwindenden Relays<br />
Xid 4 Zufallszahl, die vom Client und vom Server als<br />
Transaktions ID verwendet wird. Diese ID wird vom<br />
Client generiert.<br />
Secs 2 Zeit seit Beginn des Dialogs<br />
Flags 2 Beinhaltet ein Broadcastflag und der restliche Teil<br />
muss noch auf Null gesetzt sein. Dieser Bereich ist<br />
für Erweiterungen reserviert.<br />
Ciaddr 4 Client IP-Adresse, nur gesetzt wenn es sich um eine<br />
Erneuerung handelt z.B. bei einem Reboot<br />
Yiaddr 4 Enthält die vom Server vorgeschlagene IP-Adresse.<br />
Siaddr 4 Serveradresse, nur in <strong>DHCP</strong>OFFER und <strong>DHCP</strong>ACK<br />
Giaddr 4 Enthält gegebenenfalls die IP-Adresse eines <strong>DHCP</strong>-<br />
Relays<br />
Chaddr 16 Die Hardwareadresse des Clients<br />
Sname 64 Optional der Hostname des Servers<br />
File 128 Name eines eventuellen Bootfiles<br />
Options var Optionale Parameter<br />
6
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
3.2 Arten der Anfragen<br />
In diesem Abschnitt werden nun die verschiedenen Arten der Nachrichten in einem <strong>DHCP</strong>-<br />
Dialog zwischen Server und Client vorgestellt. Die Nachrichten sind so genannte UDP-Pakete<br />
und nutzen die Ports 67 und 68. Port 67 wird auch der „<strong>DHCP</strong>-Server-Port“ genannt und dem<br />
entsprechend Port 68 der „<strong>DHCP</strong>-Client-Port“. Dies besagt, dass alle Nachrichten vom Server<br />
an den Client auf Port 68 und die Anfragen vom Client zum Server auf Port 67.<br />
<strong>DHCP</strong>DISCOVER Bei diesem Paket handelt es sich um einen Broadcast des Clients zum<br />
auffinden eines Servers. Als Absender IP-Adresse wird die 0.0.0.0<br />
(wird solange verwendet bis der PC eine IP-Adresse zugewiesen<br />
bekommen hat) und als Empfänger-IP-Adresse die 255.255.255.255<br />
(Broadcast) verwendet.<br />
<strong>DHCP</strong>OFFER<br />
Dies ist die Serverantwort auf einen <strong>DHCP</strong>DISCOVER. Darin wird<br />
eine mögliche IP-Adresse angeboten und weitere Paramter, wie z.B. ein<br />
DNS-Server können übergeben werden. Auch diese Nachricht hat als<br />
Empfänger IP-Adresse die 255.255.255.255.<br />
<strong>DHCP</strong>REQUEST<br />
Dieses Paket kann drei verschiedene Verwendungen haben, die aber<br />
sehr stark zusammenhängen:<br />
(a) Bestätigung an einen der Server, dass dieser ausgewählt wurde und<br />
damit gleichzeitig auch die Absage an die anderen Server.<br />
(b) Bestätigung der vorhandenen Daten, zum Beispiel nach einem<br />
Reboot.<br />
(c) Zum Verlängern einer Leasezeit.<br />
<strong>DHCP</strong>ACK<br />
Hierbei handelt es sich wieder um eine Servernachricht, die dieser zum<br />
Bestätigen der Daten eines <strong>DHCP</strong>REQUEST´s sendet.<br />
<strong>DHCP</strong>NAK<br />
ist das Gegenstück zum <strong>DHCP</strong>ACK. Hiermit teilt der Server dem<br />
Client mit, dass seine IP-Adresse nicht korrekt ist (z.B. weil der Client<br />
in einem neuen Subnetz ist), oder das seine Leasezeit abgelaufen ist.<br />
<strong>DHCP</strong>DECLINE<br />
Diese Nachricht ist ähnlich <strong>DHCP</strong>NAK, jedoch gibt diese Anfrage an,<br />
dass seine IP-Adresse schon verwendet wird.<br />
<strong>DHCP</strong>RELEASE<br />
Ein solches Paket wird vom Client zum Server geschickt, wenn dieser<br />
sich abmeldet und so seine IP-Adresse wieder freigibt.<br />
<strong>DHCP</strong>INFORM<br />
Dieses Paket sendet der Client dem Server um eine Konfiguration<br />
abzufragen, wenn er extern schon eine IP-Adresse zugewiesen<br />
bekommen hat.<br />
7
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
3.3 Ablauf einer Zuordnung<br />
Fig. 2: Ze itlicher Ablauf eines <strong>DHCP</strong>-Dialogs<br />
Der Client sendet zu Beginn eines <strong>DHCP</strong>-Dialogs ein Signal, das so genannte<br />
„<strong>DHCP</strong>DISCOVER“. Da er selber keine IP-Adresse besitzt und er auch keine Adresse eines<br />
Servers kennt wird dieses Signal per Broadcast in das lokale Subnetz gesendet. Befinden sich<br />
in diesem Bereich ein oder mehrere <strong>DHCP</strong>-Server, so antworten alle mit einem<br />
8
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
„<strong>DHCP</strong>OFFER“ als Antwort. Aufgrund von Redundanz ist es gar nicht so selten, dass es<br />
nicht nur einen <strong>DHCP</strong>-Server gibt. Dieses <strong>DHCP</strong>OFFER besagt nur, hier ist ein Server, der<br />
dem anfragenden Client Dienste anbietet. Falls es also mehr als einen Server gibt, erreichen<br />
logischerweise auch mehrere Antworten den Client. Welcher Server nun ausgewählt wird, ist<br />
nicht in der RFC 2131 [4] festgelegt. Es kommt also auf die Implementierung und deren<br />
Auswahlkriterien an. In den meisten Fällen ist es jedoch so, dass nach dem FIFO-Prinzip<br />
vorgegangen wird, also die erste Antwort die den Client erreicht verwendet wird. Daraufhin<br />
sendet der Client einen <strong>DHCP</strong>REQUEST wiederum per Broadcast in sein Subnetz. Diese<br />
Nachricht enthält die IP-Adresse des ausgewählten Servers. Dieser Server sieht diese Message<br />
als Bestätigung an, alle anderen Server als Absage.<br />
Der Server wiederum bestätigt dies noch mit einem <strong>DHCP</strong>ACK. Damit hat der Client seine<br />
IP-Adresse erhalten, und der Server markiert diese in seiner internen Datenbank als „derzeit<br />
verwendet“. Der Server überträgt noch die restlichen Parameter, wie Gateway oder DNS-<br />
Server, und der Client braucht nur noch diese Daten in seine Konfiguration eintragen und ist<br />
damit fertig für den Netzwerkbetrieb.<br />
3.4 Leasezeiten<br />
In diesem Abschnitt beschäftigen wir uns mit den Leasezeiten und dem dazu gehörenden<br />
Mechanismus.<br />
Im letzten Abschnitt wurde erläutert, wie ein Client seine Konfiguration erhält. Diese erhält er<br />
aber bei der dynamischen Zuteilung nicht auf unbestimmte Zeit. Es wäre nicht sinnvoll eine<br />
Adresse so lange einem Client zu überlassen bis dieser sich abmeldet und damit die Adresse<br />
wieder freigibt. Wie oft saß man schon vor einem Rechner und es ging nichts mehr Von<br />
einem Restart bekommt der Server nichts mit, so dass diese IP-Adresse nie mehr freigegeben<br />
würde. Es gibt aber auch Implementierungen von <strong>DHCP</strong>, die ein Abmelden vom Server gar<br />
nicht beinhalten. Daher hat man sich für den so genannten Leasezeitmechanismus<br />
entschlossen.<br />
Mit der Bestätigung des Servers, also mit dem <strong>DHCP</strong>ACK, übersendet dieser dem Client<br />
auch die Gültigkeitsdauer dieser IP-Adresse. Der Client speichert sich zwei Werte T1 und T2,<br />
in der Regel ist T1 50% und T2 87,5% der Gesamtdauer. Es ist jedoch festgeschrieben, dass<br />
T1 kleiner als T2 und T2 kleiner der Leasezeit sein muss.<br />
Nach Ablauf von T1 beginnt der Client mit dem Versuch seine Leasezeit zu verlängern und<br />
sendet dem Server einen <strong>DHCP</strong>REQUEST. Daraufhin bekommt dieser vom Server wiederum<br />
einen <strong>DHCP</strong>ACK, welcher eine neue Leasetime beinhaltet. Der Client speichert die neuen<br />
Werte T1 und T2 und der Zyklus beginnt von vorne. Dieser Mechanismus wird beendet,<br />
sobald der Client sich explizit abmeldet oder der Server keine neue Leasezeit schickt. Wenn<br />
aber der Client zwischen T1 und T2 keine neue Leasezeit empfangen hat sendet dieser zwar<br />
auch noch mal einen <strong>DHCP</strong>REQUEST, diesmal jedoch wieder an alle Server. Der Client<br />
startet eine neue Initialisierungsanfrage und bekommt eine neue IP-Adresse zugeteilt.<br />
9
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
Fig. 3: Ablaufdiagramm zum Verlängern einer Leasezeit<br />
10
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
3.5 <strong>DHCP</strong>-Relay<br />
Jedes etwas größere Netzwerk wird heutzutage in verschiedene Subnetze aufgeteilt. Dafür<br />
gibt es die verschiedensten Gründe. Manchmal sind es Sicherheitsaspekte, die die<br />
Administratoren, dazu veranlassen ihr Netz in kleinere Netze aufzuspalten. Es können aber<br />
auch ganz einfach unterschiedliche Bedürfnisse für verschiedene Abteilungen in einer Firma<br />
der Grund für Subnetze sein. Um diese Subnetze zu verbinden werden Router eingesetzt. Nur<br />
was passiert wenn man <strong>DHCP</strong> in einem solchen aufgesplitteten Netzwerk einsetzen will In<br />
jedem Subnetz einen eigenen <strong>DHCP</strong>-Server aufzustellen würde den Administrationsaufwand<br />
um ein Vielfaches erhöhen. Bei Änderungen in den Netzwerkkonfigurationen zum Beispiel<br />
müsste man doch jeden Server umkonfigurieren, welches dem Sinn von <strong>DHCP</strong>, nämlich die<br />
Konfiguration zentral an einem Ort zu haben, widerspricht.<br />
Die dafür gefundene Lösung soll an dem Beispiel von Abbildung Vier erläutert werden.<br />
Fig. 4: Beispiel für <strong>DHCP</strong>-Relays mit drei verschiedenen Subnetzen<br />
11
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
Das Beispiel demonstriert ein Netzwerk mit drei verschiedenen Subnetzen. In der Realität<br />
entspricht jeder der drei Bereiche einem separaten Raum. Bereiche eins und drei sind zwei<br />
CIP-Pools, die über <strong>DHCP</strong> verwaltet werden. Es soll auch verdeutlicht werden, dass <strong>DHCP</strong><br />
nicht nur auf Computer beschränkt ist. Alle Geräte, die TCP/IP verstehen und eine IP-Adresse<br />
haben, können mit <strong>DHCP</strong> konfiguriert werden. In diesem Beispiel ist es ein Drucker im<br />
dritten Bereich. Bereich zwei zeigt den Serverraum. Hier ist der <strong>DHCP</strong>-Server untergebracht.<br />
Damit dieser Server auch Clients in anderen Subnetzen bedienen kann gibt es in jedem dieser<br />
einen sogenannten <strong>DHCP</strong>-Relay.<br />
Warum braucht man einen <strong>DHCP</strong>-Relay<br />
Die Antwort ist schnell gefunden, wenn man sich noch einmal Abschnitt 3.2 ansieht. Hieraus<br />
geht hervor, dass ein Client einen Broadcast in seinem Netz abgibt. Davon würde der <strong>DHCP</strong>-<br />
Server nichts mitbekommen, da er ja in einem anderen Netz ist. Man braucht also ein Gerät,<br />
dass einen Broadcast in in das andere Netz weiterleitet. Dies ist in der Regel ein normaler<br />
<strong>DHCP</strong>-Server, der aber keine eigene Konfiguration besitzt, sondern nur entweder den<br />
nächsten Relay oder die Adresse vom eigentlichen Server kennt. Dieser „Gateway“ ist das<br />
Bindeglied zwischen Server und Client. Er nimmt die Anfrage eines Clients entgegen, gibt<br />
diese weiter und wartet auf die Antwort des Servers, um dann dem Client seine Daten<br />
weitergeben zu können.<br />
Mit diesem Prinzip hat man es doch geschafft, die Konfiguration zentral zu halten und die<br />
Anzahl der wichtigen Server auf das Minimum zu reduzieren, welches aus Kostengründen,<br />
aber nicht in Sachen Ausfallsicherheit, anzustreben ist.<br />
12
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
4. Praktisches Beispiel<br />
Das zuvor erlangte theoretische Wissen soll nun an einem praktischen Beispiel erklärt<br />
werden. Zum Einsatz kommt eine Konfiguration eines Kölner Gymnasiums. Die folgende<br />
Konfigurationsdatei läuft auf einem AMD Athlon XP 1800+ unter SuSE Linux 8.0. Die<br />
Konfigurationsdatei des <strong>DHCP</strong>-Dämons ist in der Regel unter Linux im Verzeichnis /etc zu<br />
finden und hat den Namen „dhcpd.conf“. Die Beispielkonfiguration zeigt jedoch nur die<br />
manuelle Verteilung, um das Dokument originalgetreu zu belassen. Automatische und<br />
Dynamische Verteilungen werden in den beiden dazugehörigen Abschnitten mit Ausschnitten<br />
relevanter Konfigurationen erklärt. Es ist jedoch zu erwähnen, dass es auch durchaus möglich<br />
ist, verschiedene Vergabemodi gleichzeitig zu verwenden. In der Praxis findet man zum<br />
Beispiel oft den Fall, dass die manuelle Verteilung mit der dynamischen oder der<br />
automatischen kombiniert wird. Drucker zum Beispiel müssen immer dieselbe IP-Adresse<br />
haben, da sonst die Druckertreiber diesen nicht mehr finden würden. Das Chaos wäre<br />
vorprogrammiert. Man kann nun diesen Drucker entweder eine feste IP-Adresse per Hand<br />
geben, oder man nimmt hierfür die manuelle Verteilung. Die Rechner können jedoch<br />
trotzdem dynamisch ihre Daten erhalten. Man mag sich fragen, warum diese Schule<br />
überhaupt <strong>DHCP</strong> einsetzt, da es sich mit insgesamt ca. 70 Rechnern um ein kleines statisches<br />
Netz handelt. Der Mangel an IP-Adresse war sicher nicht der Grund dafür <strong>DHCP</strong> einzusetzen,<br />
was man auch schnell an der Konfiguration erkennen kann, da ja das Dynamische des<br />
<strong>DHCP</strong>´s gar nicht verwendet wird. Die Motivation lag einfach und allein in der<br />
Zentralisierung der Netzwerkkonfigurationen. Jeder, der auch nur mal ein kleines Netz<br />
administriert hat, weiß wie undankbar es ist, an jeden einzelnen Rechner zu müssen, nur um<br />
eine einzige Einstellung zu ändern.<br />
Der folgende Abschnitt zeigt nun die oben erwähnte, lauffähige und kommentierte Beispielkonfiguration.<br />
13
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
4.1 Konfigurationsdatei<br />
01 #************************************************<br />
02 #* <strong>DHCP</strong> - Konfigurationsskript *<br />
03 #* *<br />
04 #* verwendet auf a027fs01.irmgardis *<br />
05 #* erstellt von Nils Gräf *<br />
06 #* am 17.03.2002 *<br />
07 #* letzte Änderung am 11.05.2002 *<br />
08 #************************************************<br />
09 # Allgemeine Konfiguration:<br />
10 ddns-update-style interim;<br />
11 # Servername<br />
12 server-identifier a027fs01;<br />
13 # Leasezeiten<br />
14 default-lease-time 216000;<br />
15 max-lease-time 432000;<br />
16 # Subnetmaske<br />
17 option subnet-mask 255.255.255.0;<br />
18 # Broadcastadresse<br />
19 option broadcast-address 192.168.0.255;<br />
20 # Gateway<br />
21 option routers 192.168.0.1;<br />
22 # DNS<br />
23 option domain-name "irmgardis";<br />
24 option domain-name-servers 192.168.0.5;<br />
25 # WinS<br />
26 option netbios-name-servers a027fs01.irmgardis;<br />
27 # Nis Domain<br />
28 option nis-domain "irmgardis";<br />
29 authoritative;<br />
30 log-facility local7;<br />
31 # Vergabe von festen Adressen an den jeweiligen PC:<br />
32 subnet 192.168.0.0 netmask 255.255.255.0<br />
33 {<br />
34 }<br />
35 # E03<br />
36 host e03-ws01<br />
37 {<br />
38 hardware ethernet 00:04:75:79:8E:13;<br />
39 fixed-address 192.168.0.20;<br />
40 }<br />
41 # E04<br />
42 host e04-ws01<br />
43 {<br />
44 hardware ethernet 00:50:DA:3C:E7:F5;<br />
45 fixed-address 192.168.0.21;<br />
46 }<br />
14
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
Diese Beispielkonfiguration ist in zwei Teile aufzuspalten. Die Zeilen 1-30 stellen die<br />
allgemeinen Netzwerkinformationen dar, und die Zeilen 31-46 zeigen die Parameter zur<br />
manuellen Vergabe der IP-Adressen. Auf den zweiten Bereich wird im Abschnitt 4.2<br />
eingegangen. Zeilen, die mit einer Raute beginnen, gelten als Kommentar und dienen nur zur<br />
besseren Lesbarkeit der Datei. Mit der folgenden Tabelle wird nun der erste Teil der Datei<br />
erklärt.<br />
Zeile<br />
Bedeutung<br />
1-8 Kopf der Konfigurationsdatei<br />
10 Gibt an, wie der <strong>DHCP</strong> den DNS updaten soll<br />
11-12 Servername<br />
13-15 Definition der Leasezeiten<br />
16-17 Subnetmask<br />
18-19 Broadcastadresse<br />
20-21 Angabe des Gateways<br />
22-24 DNS - Hier wird der Name der Domain sowie die Adresse des Servers festgelegt.<br />
Es ist darauf zu achten, dass es sich bei diesem Beispiel um denselben PC handelt.<br />
25-26 WINS-Server, hier ebenfalls derselbe Rechner, dies ist aber nicht zwingend<br />
notwendig.<br />
27-28 Legt den NIS-Domainnamen fest (irmgardis)<br />
29 Macht diesen Server zu dem <strong>DHCP</strong>-Hauptserver von diesem Netz<br />
30 Legt das Log-Level des Sytemlogs (syslog) fest<br />
Diese Werte stellen Default-Werte dar, welche, falls dies aus irgendwelchen Gründen<br />
notwendig ist, überschrieben werden können. Ein möglicher Grund wäre zum Beispiel, das<br />
ein PC über eine extra Leitung mit dem Internet verbunden werden soll und daher dieser<br />
einen anderen Gateway zugewiesen bekommen muss.<br />
4.2 Manuelle Zuordnung<br />
Der zweite Teil dieser Beispielkonfiguration zeigt nun, wie man <strong>DHCP</strong> dazu nutzt einem<br />
Client immer dieselbe IP-Adresse zukommen zu lassen. Die Schule verwendet nur diesen<br />
Vergabemodus. Dieser ist praktisch, wenn man eine feste Anzahl an Rechnern hat und die<br />
Zahl der Rechner sich auf einem relativ geringen Niveau liegt. Die Anzahl der Rechner sollte<br />
aus mehreren Gründen nicht so hoch liegen, da man immer die Hardwareadresse bestimmen<br />
und in die Konfiguration eingeben muss; man schaue sich dazu zum Beispiel mal die Zeilen<br />
36 – 40 an. Hier wird einem einzelnen Rechner, nämlich dem Client „e03-ws01“ die IP-<br />
Adresse 192.168.0.20 zugewiesen. <strong>DHCP</strong> erkennt den dazugehörigen Rechner an der<br />
Hardwareadresse, die in Zeile 39 angegeben ist.<br />
15
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
4.3 Automatische Zuordnung<br />
subnet 192.168.0.0 netmask 255.255.255.0 {<br />
range 192.168.0.100 192.168.0.199;<br />
}<br />
Die Automatische Zuordnung ist eine Zuteilung ohne zeitliche Beschränkung. Der Rechner<br />
erhält einmalig eine IP-Adresse und behält diese auf unbegrenzte Zeit. In diesem Beispiel ist<br />
der zur Verfügung stehende Pool von Adressen von 192.168.0.100 bis 192.168.0.199. Eine<br />
solche Zuteilung ist zum Beispiel sinnvoll, wenn es einen großen Pool von Rechnern gibt, die<br />
jeweilige IP-Adresse im Prinzip egal ist und es nur darauf ankommt, dass die IP-Adressen<br />
nicht mehrfach vergeben werden. Im Gegensatz zu der manuellen Zuordnung, die nur für<br />
kleine Netzwerke oder Subnetze sinnvoll ist, ist diese in mittelgroßen Netzwerken sinnvoll.<br />
Solange es nicht mehr Rechner gibt als IP-Adressen zur Verfügung stehen, ist diese Zuteilung<br />
die bequemste, da man die Log-Dateien nachvollziehen kann.<br />
4.4 Dynamische Zuordnung<br />
subnet 192.168.0.0 netmask 255.255.255.0 {<br />
range 192.168.0.100 192.168.0.199;<br />
default-lease-time 21600;<br />
max-lease-time 43200;<br />
}<br />
Diese Zuteilung ist das eigentliche Herz von <strong>DHCP</strong>. Die spärlich vorhandenen IP-Adressen<br />
werden effizient ausgenutzt. Die IP-Adressen werden spätestens nach Ablauf der Leasezeit<br />
neu vergeben. Es sind immer nur so viele IP-Adressen vergeben, wie Rechner in Gebrauch<br />
sind. So ist es möglich auf einen relativ kleinen IP-Bereich viele Rechner zu verwenden. Das<br />
beste Beispiel dafür sind wohl die Internetprovider. Nie sind alle Kunden gleichzeitig online,<br />
so dass es viel zu teuer wäre, für jeden eine feste IP-Adresse zu besitzen. Der größte Nachteil<br />
liegt wohl genau in diesem Detail. Man weiß nie, welche IP-Adresse gerade ein Client hat,<br />
welches das Konfigurieren einer Firewall unter Umständen unmöglich machen kann. Bei dem<br />
oben gezeigten Beispiel werden die IP-Adressen von 192.168.0.100 bis 192.168.0.199<br />
vergeben. Die normale Leasezeit wird hier mit 21600 Sekunden, also 6 Stunden angegeben,<br />
die Maximale ist mit 43200 genau doppelt so groß.<br />
16
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
5. Zusammenfassung<br />
Das Dynamic Host Configuration Protocol ist die optimale Lösung für die Probleme, welche<br />
die Motivation zur Entwicklung von diesem Protokoll darstellten. Eine effiziente Verwaltung<br />
der zur Verfügung stehenden IP-Adressen wurde mit den drei verschiedenen Vergabemodi<br />
realisiert. Die Fernkonfiguration der Clients im Netzwerkbereich wurde ebenfalls realisiert,<br />
wie man im Kapitel 4.1 sehen kann. Auf der anderen Seite werden aber auch Nachteile<br />
deutlich und aufgedeckt.. Nach einer kurzen Einführung in das Thema beschäftigt sich das<br />
zweite Kapitel mit dem Vorgänger von <strong>DHCP</strong>, dem Bootstrap Protocol (kurz BOOTP). Im<br />
dritten Kapitel, dem eigentlichen <strong>Proseminar</strong>, wird erst auf die Entwicklung von BOOTP zu<br />
<strong>DHCP</strong> und deren Motivation eingegangen. Weiterhin werden mögliche Einsatzgebiete<br />
vorgestellt. Die Problematik mit dem verzögerten Vorstoß von IPv6 aufgrund der Vorzüge<br />
von <strong>DHCP</strong> wird am Ende der Einführung in das dritte Kapitel vorgestellt. Danach wird<br />
anhand eines Schemas ein <strong>DHCP</strong>-UDP-Paket erklärt und veranschaulicht. Nachdem der Leser<br />
erfahren hat wie ein einzelnes Paket aussieht, werden die einzelnen Arten der Anfragen<br />
erläutert. Abschnitt 3.3 zeigt den Ablauf eines Dialoges zwischen einem Client und dem<br />
Server dargestellt. Der Leasezeitmechanismus ist Bestandteil des folgenden Abschnittes.<br />
Danach folgt die Erklärung von <strong>DHCP</strong>-Relay in 3.5 anhand eines Beispiels. Dieses Beispiel<br />
wird in Kapitel 4 dann fortgeführt und anhand einer Konfigurationsdatei erklärt. Auf die<br />
Vorzüge und die Arbeitsweisen der drei Vergabemodi wird abschließend genauso<br />
eingegangen wie auf deren verschiedene Einsatzmöglichkeiten.<br />
Damit wird die Darstellung von diesem wichtigen Internetprotokoll abgerundet. Arbeitsweise<br />
und Prinzipien wurden dargestellt, sowie auf die Geschichte eingegangen.<br />
17
<strong>DHCP</strong>-<strong>Proseminar</strong><br />
6. Quellenangabe<br />
BOOTP:<br />
[1] Bill Croft, John Gilmore, RFC 951 – “Bootstrap Protocol (BOOTP)”, September<br />
1985, http://www.freesoft.org/CIE/RFC/951/<br />
[2] R. Droms,RFC 1534 – “Interoperation Between <strong>DHCP</strong> and BOOTP”,Oktober 1993,<br />
ftp://ftp.isi.edu/in-notes/rfc1534.txt<br />
[3] Gerhard Lienemann, „TCP/IP-Grundlagen“, 1996, ISBN: 3-88229-070-6<br />
<strong>DHCP</strong>:<br />
[4] R. Droms, RFC 2131 – „Dynamic Host Configuration Protocol“, März 1997,<br />
ftp://ftp.isi.edu/in-notes/rfc2131.txt<br />
[5] S. Alexander, R. Droms, RFC 2132 – „<strong>DHCP</strong> Options and BOOTP Vendor<br />
Extensions“, März 1997, ftp://ftp.isi.edu/in-notes/rfc2132.txt<br />
[6] http://www.dhcp.org<br />
[7] Uni Marburg, 22.04.2002, http://www.uni-marburg.de/hrz/komm/dhcp.html<br />
[8] Thomas Eicker, 21.04.2001, http://www.kleines-lexikon.de/w/d/dhcp.shtml<br />
[9] AWi Aktuelles Wissen Verlagsgesellschaft mbH,<br />
http://www.lanline.de/lexikon/lex/dhcp.htm<br />
[10] SONIK GmbH, http://www.sonik.ag/knowledgebase/d/dhcp.htm<br />
Praktisches Beispiel:<br />
[11] Red Hat, Inc. , Red Hat Linux 7.2 Handbuch, 2001, http://www.tuchemnitz.de/linux/Dokumentation/redhat-7.2/RH-DOCS/de/rhl-cg-de-7.2/dhcp.html<br />
[12] SuSE AG, SuSE Linux 8.0 Handbuch, 2002<br />
[13] Linux Manpages<br />
18