Diskussion:Dynamic Host Configuration Protocol/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Dynamic Host Configuration Protocol/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Dynamic_Host_Configuration_Protocol/Archiv#Thema_1

(1)

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)

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)

Da das Problem andauert, revertiere ich erneut die Abspaltung. Sollte das ein weiteres Mal mit einem Gegen-revert beantwortet werden, so werde ich dann notgedrungen eine Klärung der Frage mittels eines Löschantrages suchen. --Wahrheitsministerium 18:32, 18. Apr. 2007 (CEST)

Die Aufspaltung eines Themas in zwei verschiedene Artikel ist verwirrender als eine doppelte Kategorisierung. Ein Artikel kann problemlos in mehrere Kategorien einsortiert werden, aber der Unterschied zwischen Protokoll und Server ist in dem vorliegenden Fall zu unscharf. Im Server-Artikel werden keine konkreten Server-Implementierungen benannt, stattdessen überwiegend Protokolldetails, die daher auch in den Protokollartikel gehören (DHCP-Kommandos, Ablauf der Kommunikation, Sicherheit). --Matthäus Wander 17:33, 29. Apr. 2007 (CEST)

Konkrete Software

Es fehlt eigentlich noch die Nennung konkreter Implementierungen von DHCP-Servern. Oder spricht da etwas dagegen? Bei Webservern wird beispielsweise auch verbreitete Software genannt. Irrgärtner 10:11, 26. Sep. 2007 (CEST)

Unterschied zwischen DHCPNACK DHCPNAK?

(Der vorstehende, nicht signierte Beitrag stammt von 62.159.244.133 (Diskussion • Beiträge) 11:14, 23. Nov 2007) Fomafix 11:29, 23. Nov. 2007 (CET)

DHCPNACK gibt es nicht. Korrekt ist DHCPNAK. Siehe RFC 2131. --Fomafix 11:29, 23. Nov. 2007 (CET)

DHCPv6

Meiner Meinung nach sollte DHCPv6 in einen eigenen Artikel ausgelagert werden. Es gibt viele Änderungen (nicht nur die unterschiedlichen Ports), die in diesem Artikel den Rahmen sprengen würden. Jtb 09:30, 24. Jul. 2008 (CEST)

DHCP und DNS

"Damit ihre Namensauflösung möglich ist, registrieren Computer ihren Namen und ihre IP-Adresse in der Regel bei einem DNS-Server." Eigentlich tun sie das in der Regel gerade nicht, wenn es sich um Clients und nicht um Server handelt. Angebracht ist das sicher bei der Verwendung von DynDNS, was hier überhaupt nicht erwähnt wird, ansonsten gibt es für einen reinen Client oder Workstation wenig Gründe, sich bei einem DNS-Server registrieren zu lassen. Vielleicht ließe sich das sprachlich etwas klarer darstellen? --Burkhard 18:50, 7. Aug. 2008 (CEST)

Auf der IP-Ebene geht es um die Adressierung von Geräten. Die Aufteiluung in Client und Server ergibt nur auf der Anwendungsebene Sinn. DHCP teilt die Geräte in solche mit fest zugeteilten und solche mit zufällig zugeteilten IP-Adressen auf. Wenn ein Gerät eine zufällig zugeteilte Adresse hat, dann kann der Absender das IP-Paket nicht adressieren. Er kann die Ziel-IP-Adresse ja nicht wissen. --Kauknochen 11:31, 3. Nov. 2008 (CET)

Die DHCP-Server - ja wo laufen sie denn?

Für mich ist nach Durchsicht des Artikel zwar klar geworden, wie nützlich so ein DHCP-Server ist, aber noch nicht, wo er körperlich installiert ist. Gibt es einen Rechner im Netz, auf dem der DHCP-Server läuft? Muß man den Rechner konfigurieren oder wie sonst erfolgt die Zuordnung? Oder ist auf jedem rechner im Netz ein Stückchen DHCP-Server? --Ribald 12:52, 11. Sep. 2009 (CEST)

Einfach gesprochen: Es gibt im Netz eine Machine (das kann ein PC, ein Server oder auch ein Router sein), der als DHCP-Server fungiert. Auf dem jeweiligen Rechner, der eine Adresse erhalten soll, muss dann der passende DHCP-Client installiert sein, der entsprechend mit dem Serverdienst kommunizieren kann. Letzteres ist aber in allen halbwegs modernen Betriebssystemen vorhanden und aktiv. --magnummandel 12:56, 11. Sep. 2009 (CEST)

dhclient

finde 'dhclient' im Artikel überhaupt nicht... auch sonst nirgends in der de-WP. merkwürdig. --Itu 16:20, 11. Sep. 2009 (CEST)

Naja, was will man auch schon groß dazu schreiben ...? --Matthäus Wander 21:29, 11. Sep. 2009 (CEST)

Was sollte das denn sein? Such doch mal nach DHCP-Client, dann findest Du auch was. --Burkhard 22:25, 11. Sep. 2009 (CEST)

DHCP-Client, ahja. Ach mich hätte so ne kleine Schnellhilfe interessiert(konkret: ob man sich ne IP 'wünschen kann' .. wobei, in meinem Fall gibts eine nach innen(10.5..) und eine nach aussen). Na egal, ich weiss ich muss ja nur RTFM . gruss --Itu 22:39, 11. Sep. 2009 (CEST)

bootp vs. dhcp

hallo,

ich habe mir diese seite angeschaut, weil ich wissen wollte, wie DHCP arbeitet und sich insbesondere von BOOTP unterscheidet. das dhcp-packet sieht, so wie ich es erwartet habe, fast genauso aus wie ein bootp-packet, nur das letzte feld scheint sich zu unterscheiden (wie auch schon via netzwerksniffer festgestellt). leider ist dieses feld hier nicht beschrieben, stattdessen wird auf den RFC verwiesen. von einer seite, die sich dezidiert mit dhcp beschaeftigt, haette ich mir schon erwartet, dass das dann auch an dieser stelle abgehandelt wird. (nicht signierter Beitrag von 86.56.164.180 (Diskussion | Beiträge) 18:13, 5. Okt. 2009 (CEST))

Durch DHCP ist die automatische Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne dessen manuelle Konfiguration möglich.

1. der muss nicht neu sein --> neuen bereits von mir entfernt

2. Computer zu sehr eingeschränkt --> Idee/Vorschlag: "netzwerkfähigen Gerätes (wie z.b. Computer, Mobiltelefon, Spielekonsole oder ebookReader)" --Sven Hegermann 01:17, 22. Jan. 2010 (CET)

joa --Matthäus Wander 12:49, 22. Jan. 2010 (CET)

ein Mobiltelefon, ein ebookReader und auch eine Spielekonsole sind Computer (nicht signierter Beitrag von 212.243.87.3 (Diskussion) 10. Oktober 2013, 14:03 Uhr)

Ports in der Infobox

Da haben wir den Salat - wenn ich beim Port nicht die Richtung des Transfers angebe, dann bleibt offen, wer hier als Empfänger und wer als Sender gemeint ist. In ihrer jetzigen Knappheit ist die Portangabe in der Infobox sinnfrei. --Burkhard 23:19, 28. Jun. 2010 (CEST)

Die Ports sind sowohl in Sende- als auch Empfangsrichtung identisch und somit salatfrei. Der Server verwendet als lokalen Port immer 67, der Client immer 68. --Matthäus Wander 20:56, 29. Jun. 2010 (CEST)

Dir und mir ist klar, dass sich die Angabe in der Infobox auf den lokalen Port bezieht, aber WP:OmA eben nicht, wie der oben verlinkte Edit zeigt. Dass DHCP abhängig von der Kommunikationsrichtung ("to server, to client") zwei verschiedene Portadressen verwendet, erleichtert das Verständis dem Laien nicht unbedingt. Allerdings habe ich auch keinen Vorschlag auf Lager, wie sich das in der für eine Infobox benötigten Kürze am besten ausdrücken ließe. --Burkhard 16:06, 4. Jul. 2010 (CEST)

Der Edit sagt meines Erachtens eher etwas über die Nachlässigkeit des Benutzers und weniger über die Qualität der Infobox aus. Ein allgemeines Verständnis, wie Empfänger und Absender bei Adressen einzusetzen sind, dürfte auch bei Oma als bekannt angenommen werden. --Matthäus Wander 01:06, 5. Jul. 2010 (CEST)