Foxwiki - Benutzerbeiträge [de]

IPv4/DHCP

2021-03-25T23:24:33Z

JoergNolte: /* Ablauf der Kommunikation */

DHCP ist ein Protokoll zur dynamischen Konfiguration von Geräten in Neztwerken.

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf2.png|500px|none]]

[[File:WireDHCP2.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

= Die Lease-Dauer =

Wurde der Client über die ''Dynamische Zuweisung'' konfiguriert, wird dessen IP-Adresse nach Ablauf der ''Lease Time'' ihre Gültigkeit verlieren & kann vom Server neu vergeben werden. Dementsprechend muß der Client vor Ablauf der Lease-Dauer eine Verlängerung der Gültigkeit seiner Konfigurationsparameter anfordern:

* Client sendet ein ''DHCP-REQUEST'' an den Server, von dem er konfiguriert wurde - gewünschte IP-Adresse wird mit der Option ''Requested IP Address'' mitgeteilt
* Standardmäßig erfolgt diese Anfrage nach Ablauf von 50 Prozent der Lease-Dauer.
* Wird vom Server nicht auf diese Anfrage reagiert, sendet der Client nach Ablauf von 7/8 der Lease-Dauer eine erneute Anfrage.
* Kann der Anfrage entsprochen werden, sendet der DHCP-Server ein ''DHCP-ACK'' an den Client
* Erhält der Client kein rechtzeitiges ''DHCP-ACK'', muß dieser den Konfigurationsprozeß mit einem ''DHCP-DISCOVER'' erneut beginnen - die bisherige IP-Adresse darf bis zum Ablauf der Lease-Dauer behalten werden.

[[File:LeaseTime.png|600px|none]]

Datei:WireDHCP2.png

2021-03-25T23:22:38Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-25T23:10:35Z

JoergNolte:

DHCP ist ein Protokoll zur dynamischen Konfiguration von Geräten in Neztwerken.

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf2.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

= Die Lease-Dauer =

Wurde der Client über die ''Dynamische Zuweisung'' konfiguriert, wird dessen IP-Adresse nach Ablauf der ''Lease Time'' ihre Gültigkeit verlieren & kann vom Server neu vergeben werden. Dementsprechend muß der Client vor Ablauf der Lease-Dauer eine Verlängerung der Gültigkeit seiner Konfigurationsparameter anfordern:

* Client sendet ein ''DHCP-REQUEST'' an den Server, von dem er konfiguriert wurde - gewünschte IP-Adresse wird mit der Option ''Requested IP Address'' mitgeteilt
* Standardmäßig erfolgt diese Anfrage nach Ablauf von 50 Prozent der Lease-Dauer.
* Wird vom Server nicht auf diese Anfrage reagiert, sendet der Client nach Ablauf von 7/8 der Lease-Dauer eine erneute Anfrage.
* Kann der Anfrage entsprochen werden, sendet der DHCP-Server ein ''DHCP-ACK'' an den Client
* Erhält der Client kein rechtzeitiges ''DHCP-ACK'', muß dieser den Konfigurationsprozeß mit einem ''DHCP-DISCOVER'' erneut beginnen - die bisherige IP-Adresse darf bis zum Ablauf der Lease-Dauer behalten werden.

[[File:LeaseTime.png|600px|none]]

IPv4/DHCP

2021-03-25T23:05:28Z

JoergNolte:

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf2.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

= Die Lease-Dauer =

Wurde der Client über die ''Dynamische Zuweisung'' konfiguriert, wird dessen IP-Adresse nach Ablauf der ''Lease Time'' ihre Gültigkeit verlieren & kann vom Server neu vergeben werden. Dementsprechend muß der Client vor Ablauf der Lease-Dauer eine Verlängerung der Gültigkeit seiner Konfigurationsparameter anfordern:

* Client sendet ein ''DHCP-REQUEST'' an den Server, von dem er konfiguriert wurde - gewünschte IP-Adresse wird mit der Option ''Requested IP Address'' mitgeteilt
* Standardmäßig erfolgt diese Anfrage nach Ablauf von 50 Prozent der Lease-Dauer.
* Wird vom Server nicht auf diese Anfrage reagiert, sendet der Client nach Ablauf von 7/8 der Lease-Dauer eine erneute Anfrage.
* Kann der Anfrage entsprochen werden, sendet der DHCP-Server ein ''DHCP-ACK'' an den Client
* Erhält der Client kein rechtzeitiges ''DHCP-ACK'', muß dieser den Konfigurationsprozeß mit einem ''DHCP-DISCOVER'' erneut beginnen - die bisherige IP-Adresse darf bis zum Ablauf der Lease-Dauer behalten werden.

[[File:LeaseTime.png|600px|none]]

Datei:DHCP-Ablauf2.png

2021-03-25T23:03:26Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-24T21:24:06Z

JoergNolte: /* Die Lease-Dauer */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

= Die Lease-Dauer =

Wurde der Client über die ''Dynamische Zuweisung'' konfiguriert, wird dessen IP-Adresse nach Ablauf der ''Lease Time'' ihre Gültigkeit verlieren & kann vom Server neu vergeben werden. Dementsprechend muß der Client vor Ablauf der Lease-Dauer eine Verlängerung der Gültigkeit seiner Konfigurationsparameter anfordern:

* Client sendet ein ''DHCP-REQUEST'' an den Server, von dem er konfiguriert wurde - gewünschte IP-Adresse wird mit der Option ''Requested IP Address'' mitgeteilt
* Standardmäßig erfolgt diese Anfrage nach Ablauf von 50 Prozent der Lease-Dauer.
* Wird vom Server nicht auf diese Anfrage reagiert, sendet der Client nach Ablauf von 7/8 der Lease-Dauer eine erneute Anfrage.
* Kann der Anfrage entsprochen werden, sendet der DHCP-Server ein ''DHCP-ACK'' an den Client
* Erhält der Client kein rechtzeitiges ''DHCP-ACK'', muß dieser den Konfigurationsprozeß mit einem ''DHCP-DISCOVER'' erneut beginnen - die bisherige IP-Adresse darf bis zum Ablauf der Lease-Dauer behalten werden.

[[File:LeaseTime.png|600px|none]]

IPv4/DHCP

2021-03-24T21:01:35Z

JoergNolte:

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

= Die Lease-Dauer =

[[File:LeaseTime.png|600px|none]]

Datei:LeaseTime.png

2021-03-24T21:01:00Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-24T20:29:11Z

JoergNolte: /* Ablauf der Kommunikation */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T20:23:24Z

JoergNolte: /* Aufbau von DHCP-Nachrichten */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T20:12:34Z

JoergNolte: /* Ablauf der Kommunikation */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T20:11:54Z

JoergNolte: /* Ablauf des DHCP-Verfahrens */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Zuweisungsmethoden des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T19:40:37Z

JoergNolte: /* DHCP_Nachrichten */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Ablauf des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP-Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T19:40:23Z

JoergNolte: /* Ablauf des DHCP-Verfahrens */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

= Ablauf des DHCP-Verfahrens =

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T19:30:21Z

JoergNolte: /* Ablauf der Kommunikation */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:DHCP-Ablauf1.png|500px|none]]

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

Datei:DHCP-Ablauf1.png

2021-03-24T19:29:05Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-24T09:21:03Z

JoergNolte: /* Ablauf der Kommunikation */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
* ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

* Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
* angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-24T07:47:13Z

JoergNolte: /* Ablauf des DHCP-Verfahrens */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
* erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255)
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' an den ausgewählten DHCP-Server (''sname'')
* angebotene IP-Adresse kann mit der Option ''Requested IP Address'' bestätigt werden
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-23T22:43:19Z

JoergNolte:

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

[[File:DHCP-Paket.png|400px|none]]

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255)
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' an den ausgewählten DHCP-Server (''sname'')
* angebotene IP-Adresse kann mit der Option ''Requested IP Address'' bestätigt werden
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

Datei:DHCP-Paket.png

2021-03-23T22:42:18Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-23T22:41:08Z

JoergNolte: /* Ablauf der Kommunikation */

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255)
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' an den ausgewählten DHCP-Server (''sname'')
* angebotene IP-Adresse kann mit der Option ''Requested IP Address'' bestätigt werden
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:DHCP-Phasen.png|1600px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

Datei:DHCP-Phasen.png

2021-03-23T22:37:56Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-23T18:41:16Z

JoergNolte:

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255)
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' an den ausgewählten DHCP-Server (''sname'')
* angebotene IP-Adresse kann mit der Option ''Requested IP Address'' bestätigt werden
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

[[File:WireShark-DHCP-Phasen.png|1000px|none]]

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

Datei:WireShark-DHCP-Phasen.png

2021-03-23T18:33:31Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

IPv4/DHCP

2021-03-23T11:44:11Z

JoergNolte:

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

== Anforderungen an den DHCP-Server ==

* Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
* Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
* Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
* Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

== Ablauf des DHCP-Verfahrens ==

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255)
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' an den ausgewählten DHCP-Server (''sname'')
* angebotene IP-Adresse kann mit der Option ''Requested IP Address'' bestätigt werden
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

IPv4/DHCP

2021-03-23T11:28:23Z

JoergNolte: Die Seite wurde neu angelegt: „ = Historie = * DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und au…“

= Historie =

* DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren
* Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
* Ablösung durch neue Version in RFC 2131 im März 1997
* Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

= Grundlagen =

* DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
* DHCP funktioniert nach dem Client-Server-Prinzip
* Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
* IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
* Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

* Client-IP-Adresse
* Lease-Dauer
* Identifikation des DHCP-Servers
* Subnetzmaske
* Default-Gateways
* statische Routen
* Hostname & Domainname
* Lokation externer Server (z. Bsp. Time-Server)

'''Automatische Zuweisung''':

* IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
* Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
* Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

'''Dynamische Zuweisung''':

* Vergabe erfolgt analog der ''Automatischen Zuweisung''
* Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
* Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
* Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen

'''Manuelle Zuweisung''':

* DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
* Client erhält immer die gleiche IP-Adresse
* nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
* sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

= DHCP_Nachrichten =

* Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
* Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
* Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
* Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

== Aufbau von DHCP-Nachrichten ==

{| class="wikitable"
|-
! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
|-
| op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
|-
| htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
|-
| hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
|-
| hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
|-
| xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
|-
| secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
|-
| flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
|-
| ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
|-
| yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
|-
| siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
|-
| giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
|-
| chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
|-
| sname || 64 || Server-Name ||
|-
| file || 128 || File / Datei ||
|-
| options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
|}

== Ablauf der Kommunikation ==

'''Anforderungsphase''':

* Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255)
* Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
* Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
* Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

'''Angebotsphase''':

* Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
* Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:
* Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
* Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:
* Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
* Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

'''Auswahlphase''':

* Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
* Senden einer Nachricht ''DHCP-REQUEST'' an den ausgewählten DHCP-Server (''sname'')
* angebotene IP-Adresse kann mit der Option ''Requested IP Address'' bestätigt werden
* Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

'''Bestätigungsphase''':

* Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
* Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

'''Weitere DHCP-Nachrichtentypen''':

''DHCP-NAK'':
* wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

''DHCP-RELEASE'':
* Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

''DHCP-DECLINE'':
* Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

''DHCP-INFORM'':
* Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.

Internet Control Message Protocol

2021-03-08T18:37:43Z

JoergNolte: /* Umleitung im Netzwerk */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo Reply || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
|-
|rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
|-
| 1 || Benachrichtigung über eine Umleitung für den ausgewählten Host
|-
| 2 || Umleitung für den angegebenen Dienst & das Netz
|-
| 3 || Umleitung für den angegebenen Dienst & den Host
|-
| 8 || Echo Request || 0 || Echo-Anfrage (Ping)
|-
| 9 || Router Solicitation || 0 || Suche nach einem Router
|-
| 10 || Router Advertisement || 0 || Bekanntmachung eines Routers
|-
|rowspan="2"| 11 || rowspan="2"| Time Exceeded || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

[[File:ICMP-traceroute.png| 600px |none]]

== Pfad-MTU Ermittlung ==

Eine weitere wichtige Funktion von ICMP ist ein Verfahren zur Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' für ein entferntes IP-Netz. Dieses wird als ''Path MTU Discovery'' bezeichnet und ist von jedem Router zu unterstützen.

Ablauf zur Ermittlung der MTU:

* Der Sender generiert ein IP-Paket mit der MTU des lokalen Netzes und gesetztem ''Don't Fragment''-Bit
* Wird auf dem Weg ein Transfernetz erreicht, dessen MTU überschritten wird, so daß dessen Router das Paket fragmentieren müsste, wird das Paket verworfen und der Absender durch eine ICMP-Nachricht vom Typ 3 Code 4 (''Destination Unreachable'',''Fragmentation required, and DF flag set'') benachrichtigt.
* Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden.

== Umleitung im Netzwerk ==

Wird von einem Router bemerkt, daß es für ein IP-Paket einen schnelleren Weg zum Ziel gibt, kann er den Absender darüber informieren. Dies geschieht mit einer ICMP-Nachricht vom Typ ''Redirect'':

* Rechner '''B''' möchte Daten an Rechner '''A''' versenden und sendet diese an seinen Standard-Router '''R2''' (1)
* Router '''R2''' übergibt die Daten an Router '''R1''', der diese an den Zielrechner '''A''' weiterleitet (2)
* Router '''R2''' erkennt jedoch, daß es für Rechner '''A''' günstiger wäre, sich gleich an Router '''R1''' zu wenden und teilt ihm dieses durch eine ICMP-Nachricht vom Typ ''Redirect'' mit (3)
* Rechner '''B''' sendet fortan die Daten direkt zu Router '''R1''' (4)

[[File:ICMP-Redirect.png|600px|none]]

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-08T18:37:09Z

JoergNolte: /* Trace Route */

Datei:ICMP-traceroute.png

2021-03-08T18:35:55Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

Internet Control Message Protocol

2021-03-08T13:47:21Z

JoergNolte: /* Anwendungen */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo Reply || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
|-
|rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
|-
| 1 || Benachrichtigung über eine Umleitung für den ausgewählten Host
|-
| 2 || Umleitung für den angegebenen Dienst & das Netz
|-
| 3 || Umleitung für den angegebenen Dienst & den Host
|-
| 8 || Echo Request || 0 || Echo-Anfrage (Ping)
|-
| 9 || Router Solicitation || 0 || Suche nach einem Router
|-
| 10 || Router Advertisement || 0 || Bekanntmachung eines Routers
|-
|rowspan="2"| 11 || rowspan="2"| Time Exceeded || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

== Pfad-MTU Ermittlung ==

Eine weitere wichtige Funktion von ICMP ist ein Verfahren zur Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' für ein entferntes IP-Netz. Dieses wird als ''Path MTU Discovery'' bezeichnet und ist von jedem Router zu unterstützen.

Ablauf zur Ermittlung der MTU:

* Der Sender generiert ein IP-Paket mit der MTU des lokalen Netzes und gesetztem ''Don't Fragment''-Bit
* Wird auf dem Weg ein Transfernetz erreicht, dessen MTU überschritten wird, so daß dessen Router das Paket fragmentieren müsste, wird das Paket verworfen und der Absender durch eine ICMP-Nachricht vom Typ 3 Code 4 (''Destination Unreachable'',''Fragmentation required, and DF flag set'') benachrichtigt.
* Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden.

== Umleitung im Netzwerk ==

Wird von einem Router bemerkt, daß es für ein IP-Paket einen schnelleren Weg zum Ziel gibt, kann er den Absender darüber informieren. Dies geschieht mit einer ICMP-Nachricht vom Typ ''Redirect'':

* Rechner '''B''' möchte Daten an Rechner '''A''' versenden und sendet diese an seinen Standard-Router '''R2''' (1)
* Router '''R2''' übergibt die Daten an Router '''R1''', der diese an den Zielrechner '''A''' weiterleitet (2)
* Router '''R2''' erkennt jedoch, daß es für Rechner '''A''' günstiger wäre, sich gleich an Router '''R1''' zu wenden und teilt ihm dieses durch eine ICMP-Nachricht vom Typ ''Redirect'' mit (3)
* Rechner '''B''' sendet fortan die Daten direkt zu Router '''R1''' (4)

[[File:ICMP-Redirect.png|600px|none]]

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Datei:ICMP-Redirect.png

2021-03-08T13:28:19Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

Internet Control Message Protocol

2021-03-08T10:39:37Z

JoergNolte: /* Anwendungen */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo Reply || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
|-
|rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
|-
| 1 || Benachrichtigung über eine Umleitung für den ausgewählten Host
|-
| 2 || Umleitung für den angegebenen Dienst & das Netz
|-
| 3 || Umleitung für den angegebenen Dienst & den Host
|-
| 8 || Echo Request || 0 || Echo-Anfrage (Ping)
|-
| 9 || Router Solicitation || 0 || Suche nach einem Router
|-
| 10 || Router Advertisement || 0 || Bekanntmachung eines Routers
|-
|rowspan="2"| 11 || rowspan="2"| Time Exceeded || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

== Pfad-MTU Ermittlung ==

Eine weitere wichtige Funktion von ICMP ist ein Verfahren zur Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' für ein entferntes IP-Netz. Dieses wird als ''Path MTU Discovery'' bezeichnet und ist von jedem Router zu unterstützen.

Ablauf zur Ermittlung der MTU:

* Der Sender generiert ein IP-Paket mit der MTU des lokalen Netzes und gesetztem ''Don't Fragment''-Bit
* Wird auf dem Weg ein Transfernetz erreicht, dessen MTU überschritten wird, so daß dessen Router das Paket fragmentieren müsste, wird das Paket verworfen und der Absender durch eine ICMP-Nachricht vom Typ 3 Code 4 (''Destination Unreachable'',''Fragmentation required, and DF flag set'') benachrichtigt.
* Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden.

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-08T10:03:23Z

JoergNolte: /* ICMP-Header */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo Reply || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
|-
|rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
|-
| 1 || Benachrichtigung über eine Umleitung für den ausgewählten Host
|-
| 2 || Umleitung für den angegebenen Dienst & das Netz
|-
| 3 || Umleitung für den angegebenen Dienst & den Host
|-
| 8 || Echo Request || 0 || Echo-Anfrage (Ping)
|-
| 9 || Router Solicitation || 0 || Suche nach einem Router
|-
| 10 || Router Advertisement || 0 || Bekanntmachung eines Routers
|-
|rowspan="2"| 11 || rowspan="2"| Time Exceeded || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-08T09:36:53Z

JoergNolte: /* ICMP-Header */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo Reply || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
|-
|rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
|-
| 1 || Benachrichtigung über eine Umleitung für den ausgewählten Host
|-
| 2 || Umleitung für den angegebenen Dienst & das Netz
|-
| 3 || Umleitung für den angegebenen Dienst & den Host
|-
| 8 || Echo Request || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Time Exceeded || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-08T02:17:48Z

JoergNolte: /* ICMP-Daten */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-08T02:04:16Z

JoergNolte:

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim ''Ping of Death'' wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-07T23:49:19Z

JoergNolte:

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

* Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
* Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

* Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
* Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
* Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
* Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
* Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.

= Missbrauch =

== Ping flood ==

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

== Ping of Death ==

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-07T23:19:20Z

JoergNolte:

Internet Control Message Protocol

2021-03-03T08:00:23Z

JoergNolte: /* Die Paketstruktur */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

== ICMP-Header ==

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

== ICMP-Daten ==

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

= Missbrauch =

== Ping flood ==

== Ping of Death ==

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-03T07:57:28Z

JoergNolte:

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

= Missbrauch =

== Ping flood ==

== Ping of Death ==

= Kontrollfragen =

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

<div class="toccolours mw-collapsible mw-collapsed">
?
<div class="mw-collapsible-content">
A:
</div>
</div>

Internet Control Message Protocol

2021-03-03T07:53:58Z

JoergNolte:

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Internet Control Message Protocol

2021-03-02T14:04:10Z

JoergNolte: /* Ping */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

= Die Paketstruktur =

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

[[File:Ping.png|750px|none]]

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Datei:Ping.png

2021-03-02T13:21:46Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

Internet Control Message Protocol

2021-03-02T12:53:51Z

JoergNolte: /* Die Paketstruktur */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[File:ICMP4.png|750px|none]]

= Die Paketstruktur =

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Datei:ICMP4.png

2021-03-02T12:51:24Z

JoergNolte: Datei hochgeladen mit MsUpload

Datei hochgeladen mit MsUpload

Internet Control Message Protocol

2021-03-02T10:39:40Z

JoergNolte: /* Grundlagen */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

= Die Paketstruktur =

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[Datei:ICMP3.png|800px|ohne]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Internet Control Message Protocol

2021-03-02T10:27:44Z

JoergNolte: /* Die Paketstruktur */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist.

= Die Paketstruktur =

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format:
*Mit dem ersten Byte wird der Typ der Nachricht kodiert.
*Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
*Das dritte und vierte Byte bilden eine Prüfsumme des Headers
Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.

[[Datei:ICMP3.png|800px|ohne]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Internet Control Message Protocol

2021-03-02T10:19:28Z

JoergNolte: /* Die Paketstruktur */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist.

= Die Paketstruktur =

Der Header einer ICMP-Nachricht:
*folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
*besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe
Die ersten vier Bytes des Headers haben ein festgelegtes Format, währen die folgenden vier Bytes vom Typ der ICMP-Nachricht abhängen.

[[Datei:ICMP3.png|800px|ohne]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Internet Control Message Protocol

2021-03-02T10:11:01Z

JoergNolte: /* Die Paketstruktur */

Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an die Absender-IP-Adresse.

= Historie =

* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]

= Grundlagen =

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

* ein Gerät oder Dienst ist nicht ereichbar
* einzelne Bits der Datagramme wurden auf dem Weg verfälscht
* die Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist.

= Die Paketstruktur =

Der Header einer ICMP-Nachricht folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt. Dieser Header erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen. Er besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe.

[[Datei:ICMP3.png|800px|ohne]]

{| class="wikitable toptextcells"
|-
! Typ !! Typname !! Code !! Bedeutung
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|-
| 1 || Host (Zielstation) nicht erreichbar
|-
| 2 || Protokoll nicht erreichbar
|-
| 3 || Port nicht erreichbar
|-
| 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
|-
| 5 || Route nicht möglich
|-
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
|-
| 1 || Zeitlimit während der Defragmentierung überschritten
|}

= Anwendungen =

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

* Ziel nicht erreichbar (''Destination Unreachable''): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.

* Zeit überschritten (''Time Exceeded'')

* Ungültige Parameter (''Parameter Problem'')

* Senderate reduzieren (''Source Quench'')

* Umleitung im Netzwerk (''Redirect'')

* Prüfung auf die Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

== Ping ==

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht ''Echo Request'' an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem ''Echo Reply''.

$ ping google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

== Trace Route ==

Mit dem Kommandozeilenbefehl '''traceroute''' kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird:

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms

== Trace Path ==

= Missbrauch =

== Ping flood ==

== Ping of Death ==

Datei:ICMP3.png

2021-03-01T10:27:38Z

JoergNolte:

ICMP-Header