Diskussion:Dynamic Host Configuration Protocol

Der Protokollstapel im Artikel ist lustig... DHCP ist eigentlich ein schönes Beispiel dafür, dass das Layer-Modell manchmal an seine Grenzen stößt. Fast die ganze DHCP-Kommunikation läuft ja m.E. zu einem Zeitpunkt ab, an dem IP überhaupt noch nicht konfiguriert ist. Der Client sendet statt dessen an die Broadcast-MAC und später unter Umgehung von Schicht 3 an die MAC, die er im Antwortpaket des Servers vorfand. Die Aufnahme von IP in den Stapel scheint mir deshalb etwas fragwürdig. Kann mich diesbezüglich mal jemand erleuchten? --Echoray 22:05, 26. Nov 2003 (CET)

Die Aufnahme von IP ist ja der Trick an der ganzen Sache. DHCP übernimmt dabei das Konzept von BOOTP (es erweitert eigentlich BOOTP nur). Ich erkläre mal BOOTP, da es vom Einsatzzweck her einfacher ist. BOOTP dient zum Konfigurieren der IP-Adresse wenn nichts bekannt ist. Dazu diente früher RARP, das einfach die MAC-Adresse als Ethernetbroadcast auf die Reise schickt und dann eine Antwort vom RARP-Server bekommt. Danach kennt es seine IP-Adresse und nur seine IP-Adresse. Das hat folgende Nachteile:

• Die Netmask ist nicht bekannt, daher weiss das Gerät nicht, was lokale Adressen sind und was geroutet werden soll
• Es ist auch kein Gateway bekannt.

BOOTP behebt nun diese Probleme, indem es weitere Parameter zulässt (Netzmaske, IP-Gateway, Boot-Server usw., Nameserver,...). DHCP ist eigentlich eine Erweiterung von BOOTP um Hostparameter (Drucker, Timeserver usw.)

Achtung, jetzt kommt der Trick 1

Wenn BOOTP/DHCP einen Ethernet-Broadcast zusammenbasteln, fügen sie immer einen korrekten IP-Header ein. Wie können sie das ohne Ziel-IP-Adresse? Antwort: Es wird der allgemeine IP-Broadcast 255.255.255.255 verwendet. Ausserdem fügen sie noch einen UDP-Header ein. Damit sind dann Länge/Cheksumme der Daten gesichert. IP/UDP wird eh dann für TFTP gebraucht, wenn man plattenlos booten will. Wenn auf Fragmentierung verzichtet wird, kann man's sehr einfach im ROM implementieren (ARP/IP/UDP/BOOTP/TFTP genügen zum plattenlosen Booten). Was soll das?

Achtung, jetzt kommt der Trick 2

Bei Ethernet-Broadcasts ist das Problem, dass die Nachrichten auf Subnetze beschränkt sind. Ich brauche also eigentlich einen DHCP/BOOTP-Server im selben Subnetz. An grossen Einrichtungen sind aber viele Subnetze (Unis einige hundert) vorhanden. Ich will aber keinen Server in jedem Minisubnetz betreiben. DHCP läuft ja nicht von allein, sondern will konfiguriert werden.

So, und die (teureren) Router an diesen Einrichtungen erlauben die Konfiguration eines BOOTP-Helpers (der auch DHCP-Helper sein kann). Wenn ein Ethernet-Broadcast auf einem Subnetz an einem Interface eintrifft, schauen die Router auf das Typfeld (ob's IP ist) und dann auf's Protokollfeld (ob's BOOTP/DHCP ist). Wenn dies der Fall ist, ersetzen diese die IP-Broadcast-Adresse durch die konfigurierte BOOTP-Helperadresse und routen das Paket weiter. Das Paket hat jetzt eine richtige Adresse und kann theoretisch im ganzen Internet geroutet werden. Der DHCP-Server kennt ja auch die Ziel-IP-Adresse und sendet ein routbares Paket zurück. Ich brauche also nur einen DHCP-Server und kann dann BOOTP-Helper in den Routern meiner Subnetze konfigurieren. Damit genübt mein einziger DHCP-Server (oder zwei wg. Redundanz) für alle meine Subnetze.

Ich hoffe ich hab's einigermaßen rübergebracht Hubi 08:10, 27. Nov 2003 (CET)

Noch was: Es gibt keine Möglichkeit, Layer wegzulassen. Es gibt z.B. kein Ethernet-Typfeld für UDP, nur eines IPv4 und IPv6. Um ein BOOTP/DHCP-Paket loszuschicken, kann ich also nicht einfach ein Ethernet-Paket wegschicken und UDP darin verpacken. Ich muss also etwa 0x800 für IPv4 verwenden. Dann füge ich einen IP-Header ein, mit Protokoll 17₁₀ für UDP und dort in den Zielport dann BOOTP/DHCP. Die Geräte sind also gezwungen, die 20 IP-Header-Bytes, die eigentlich überflüssig sind, einzufügen. Der Bootp-Helper tut sich dann umso leichter. Hubi 08:31, 27. Nov 2003 (CET)

Noch was: RFC951, Abschnitt 6 (Vergleich zu RARP) hat mich drauf gebracht. Auf dem Server unter Unix/Linux kann ein bootpd oder dhcpd als ganz normaler, unprivilegierter Prozess (wenn man mal von dem privilegierten Port absieht) ohne besondere Kerneltreiber, Raw-Packet Unterstützung etc. implementiert werden. Dies ist bei RARP (braucht Raw-Packet Priviledge -> SUID-Bit) nicht der Fall. Dies ist Folge des Standardformats (Ethernet/IP/UDP/DHCP). Würde man den IP-Header weglassen, wäre dies nicht mehr der Fall Hubi 10:00, 27. Nov 2003 (CET)

Hi, eure Diskussion ist wirklich gut gelaufen. Sie kann ja in den Artikel eingearbeitet werden - viele Artikelleser (so wie auch ich) werden sich garantiert fragen, wie DHCP auf Anwendungsebene laufen kann, bevor überhaupt eine IP vergeben ist. Ciao, --Abdull 23:47, 31. Mär 2005 (CEST)

wahl zwischen verschiedenen offers?!

im text steht etwas davon das sich der client aussucht von wem er einen offer annimmt. zudem wird als beispiel die verschiedene leasezeit der angebotenen ip's genannt. 1. wählt der client aus? dachte bisher dass einfach das erste offer angenommen wird. 2. kann er nach leasezeit selektieren? die leasezeit wird doch erst beim ack mitgeteilt wie kann er da beim offer schon ne auswahl anhand der leasezeit treffen?

zu 1. Auf jeden Fall wählt der Client aus. Z.B. kann beim ISC-Client mittels "reject" das Angebot eines DHCP-Servers abgelehnt werden (v. a. wenn der falsch konfiguriert ist).

zu 2. Mit Lease-Zeit-Selektion hab ich mich nicht beschäftigt - müsste den genauen Inhalt des Offers nochmal nachschauen ... (wenns drin ist, hängt die Selektionsmöglichkeit sicher auch vom Client ab).

ich war wohl nicht so fit als ich den kommentar gepostet habe. :) ok, der client kann auswählen und dieses auch anhand der schon beim offer mitgelieferten lease-time machen. shame on me.

warnung

Ich habe die Warnung rausgenommen. Aus professioneller Sicht ist der zusätzliche Sicherheitsgewinn durch Abschalten des DHCP minimal. Ein kompetenter Hacker kommt auch ohne DHCP schnell weiter. Damit hält man nur Dilettanten fern. --Hubi 07:29, 22. Jun 2006 (CEST)

Sinnhaftigkeit der Abspaltung großer Teile des Artikels

Ich verstehe wohl den Unterschied zwischen Protokoll und Server und die theoretische Rechtfertigung einer Trennung der Beiden. Die entfernten Passagen enthalten jedoch auch Teile zum Protokoll und im Sinne einer übersichtlichen Erörterung des Themas halte ich es für sinnvoll, es bei einem Artikel zu belassen. --Wahrheitsministerium 06:37, 11. Apr. 2007 (CEST)

Habe die Trennung vorgenommen weil sonst die Kategorisierung unverständlich ist --Staro1 06:54, 11. Apr. 2007 (CEST)

Ich denke Kundenfreundlichkeit sollte hier Vorrang vor Kategorisierungsschwierigkeiten haben. Die verschiedenen Befehle gehören unstrittig zum Protokoll, die Trennung erschwert das Verständnis erheblich und wird selbst wenn das korrigiert wird, permanente Duplizierung von Inhalten nach sich ziehen. Das scheint mir ein zu hoher Preis zur Lösung eines Kategorisierungsproblems (welches eigentlich ?) zu sein. --Wahrheitsministerium 07:18, 11. Apr. 2007 (CEST)

? wieso gehören Serverbefehle zum Protokoll ? sehe keinen Platz im Paket! --Staro1 03:23, 12. Apr. 2007 (CEST)

Vielleicht veranlasst Dich ja die späte Stunde zu solchen Satzruinen. Für eine etwas elaboriertere Argumentation wäre ich Dir sehr dankbar. Die Lektüre des RFC wird inzwischen sicher auch Dich davon überzeugt haben, daß die Befehle ohne jede Frage zum Protokoll gehören. --Wahrheitsministerium 12:36, 12. Apr. 2007 (CEST)

warum soll ich darüber streiten ? Ein "Protokoll" ist nicht konfigurierbar. Ich will aber diesen Artikel nicht gleichzeitig als Protokoll und als Daemon kategorisieren, das wäre verwirrend. --Staro1 00:29, 14. Apr. 2007 (CEST)

Vielen Dank für eine Antwort in ganzen Sätzen. Mir ist nicht entgangen, daß Deine Schwierigkeiten, den Artikel zu kategorisieren, Dich dazu veranlasst haben, ihn ohne Rücksicht auf Inhalte, die sachlich richtige Verteilung derselben und die Verständlichkeit für den Leser zu teilen. Kategorien sind kein Selbstzweck auf Kosten der Lesbarkeit. Kommentarlose reverts und Antworten, die, wenn sie denn kommen, im Telegrammstil vermeiden auf differenzierte Kritik einzugehen, machen mich etwas ratlos. Ich möchte weder einen editwar lostreten, noch finde ich den jetzigen Zustand auch nur annähernd befriedigend. Während ich über sinnvolle nächtste Schritte nachdenke um das Problem zu beheben, stehe ich eventuell noch kommenden inhaltlichen Argumenten nach wie vor aufgeschlossen gegenüber. --Wahrheitsministerium 01:07, 14. Apr. 2007 (CEST)