Internet Control Message Protocol: Unterschied zwischen den Versionen

Aus Foxwiki
(Die Seite wurde neu angelegt: „Das '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) ist eine Erweiterung des Internet-Protokolls (IP) und dient der Fehlerberichterstattung an…“)
 
Markierung: Manuelle Zurücksetzung
 
(178 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
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.
'''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol (ICMP) - Austausch von Statusinformationen der IP-Verbindung


= Historie =
== Beschreibung ==
* Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebige Pfade
* Treten dabei Fehler auf, kann ICMP den Absender informieren


* ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
; Mögliche Probleme
* Verabschiedung des ersten Standards im April 1981 als [https://tools.ietf.org/html/rfc777 RFC 777]
* Gerät oder Dienst ist nicht erreichbar
* mehrmalige Aktualisierungen führten zur aktuellen Definition [https://tools.ietf.org/html/rfc792 RFC 792]
* Header-Daten wurden verfälscht
 
= 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 Lebenszeit (TTL) eines Datagramms ist abgelaufen
* die Pufferkapazität des Empfängers ist erschöpft
* 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.
; OSI-Schicht 3
* 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 =
== Fehlerermittlung ==
 
; Situationen, die eine ICMP-Fehlermeldung auslösen
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.
{| class="wikitable options"
 
! Grund !! Fehler !! Auslöser
{| class="wikitable" style="text-align:center;"
|-
|- style="text-align:left; background-color:#34cdf9;"
| 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
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 0
|-
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 1
| Zeit überschritten || Time Exceeded ||
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 2
|-
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 3
| Ungültige Parameter || Parameter Problem ||
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 4
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 5
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 6
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 7
! style="background-color:#dae8fc;" | 8
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 9
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 10
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 11
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 12
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 13
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 14
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;; background-color:#dae8fc;" | 15
! style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | 16
! 17
! 18
! 19
! 20
! 21
! 22
! 23
! style="background-color:#dae8fc;" | 24
! style="background-color:#dae8fc;" | 25
! style="background-color:#dae8fc;" | 26
! style="background-color:#dae8fc;" | 27
! style="background-color:#dae8fc;" | 28
! style="background-color:#dae8fc;" | 29
! style="background-color:#dae8fc;" | 30
! style="background-color:#dae8fc;" | 31
|-
|-
| colspan="8" style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | Typ (Byte 1)
| Senderate reduzieren || Source Quench ||
| colspan="8" style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | Code (Byte 2)
| colspan="16" style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | Prüfsumme (Byte 3 & 4)
|-
|-
| colspan="32" style="font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | Verschiedenes bzw. ungenutzt (Byte 5 bis 8)
| Umleitung im Netzwerk || Redirect ||
|- style="text-align:left;"
| colspan="32" style="text-align:center; font-family:'Lucida Sans Unicode', 'Lucida Grande', sans-serif !important;;" | Daten
|}
|}


[[Datei:ICMP3.png|800px|ohne]]
* Prüfung auf Erreichbarkeit eines Gerätes
* Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
* Ermittlung der maximalen Größe des Datagramms auf diesem Pfad


{| class="wikitable toptextcells"
== Paketstruktur ==
=== Header ===
[[File:ICMP4.png|mini|500px]]
 
Der ICMP-Header folgt direkt auf den IPv4-Header
* wird an der Protokollnummer erkannt
* Erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
* Länge: 8 Byte + Datenabschnitt variabler Größe
 
: Format der ersten vier Bytes
* 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 vier Bytes sind vom Typ der ICMP-Nachricht abhängig
 
{| class="wikitable options big"
|-
|-
! Typ !! Typname !! Code !! Bedeutung
! Typ !! Typname !! Code !! Bedeutung
|-
|-
| 0 || Echo-Antwort || 0 || Echo-Antwort
| 0 || Echo Reply || 0 || Echo-Antwort
|-
|-
|rowspan="7"| 3 || rowspan="7"| Ziel nicht erreichbar || 0 || Netzwerk nicht erreichbar
|rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
|-
|-
| 1 || Host (Zielstation) nicht erreichbar
| 1 || Host (Zielstation) nicht erreichbar
Zeile 88: Zeile 70:
| 13 || Paket wird von der Firewall des Empfängers geblockt
| 13 || Paket wird von der Firewall des Empfängers geblockt
|-
|-
| 4 || Entlasten der Quelle || 0 || Datagramm verworfen, da Warteschlange voll
| 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
|-
|-
| 8 || Echo-Anfrage || 0 || Echo-Anfrage (Ping)
|rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
|-
|-
|rowspan="2"| 11 || rowspan="2"| Zeitlimit überschritten || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
| 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
| 1 || Zeitlimit während der Defragmentierung überschritten
|}
|}


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


Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:
== Anwendung ==
 
{| class="wikitable options big"
* 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.
|-
 
| Erreichbarkeit prüfen || [[ping]]
* Zeit überschritten (''Time Exceeded'')
|-
 
| Weg nachvollziehen || [[traceroute]]
* Ungültige Parameter (''Parameter Problem'')
|-
 
| Maximale Path-MTU ermitteln || [[Path MTU Discovery]]
* Senderate reduzieren (''Source Quench'')
|-
 
| Umleitung im Netzwerk || [[IPv4/ICMP/Redirect]]
* 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
<noinclude>
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 ==
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
{{Special:PrefixIndex/ICMP}}


= Missbrauch =
==== Dokumentation ====
===== RFC =====
# https://tools.ietf.org/html/rfc792


== Ping flood ==
==== Links ====
===== Weblinks =====


== Ping of Death ==
[[Kategorie:IPv4]]
[[Kategorie:ICMP]]
</noinclude>

Aktuelle Version vom 27. Februar 2024, 21:32 Uhr

Internet Control Message Protocol (ICMP) - Austausch von Statusinformationen der IP-Verbindung

Beschreibung[Bearbeiten | Quelltext bearbeiten]

  • Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebige Pfade
  • Treten dabei Fehler auf, kann ICMP den Absender informieren
Mögliche Probleme
  • Gerät oder Dienst ist nicht erreichbar
  • Header-Daten wurden verfälscht
  • die Lebenszeit (TTL) eines Datagramms ist abgelaufen
  • die Pufferkapazität des Empfängers ist erschöpft
OSI-Schicht 3
  • 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

Fehlerermittlung[Bearbeiten | Quelltext bearbeiten]

Situationen, die eine ICMP-Fehlermeldung auslösen
Grund Fehler Auslöser
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 Erreichbarkeit eines Gerätes
  • Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
  • Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

Paketstruktur[Bearbeiten | Quelltext bearbeiten]

Header[Bearbeiten | Quelltext bearbeiten]

Der ICMP-Header folgt direkt auf den IPv4-Header

  • wird an der Protokollnummer erkannt
  • Erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
  • Länge: 8 Byte + Datenabschnitt variabler Größe
Format der ersten vier Bytes
  • 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 vier Bytes sind vom Typ der ICMP-Nachricht abhängig
Typ Typname Code Bedeutung
0 Echo Reply 0 Echo-Antwort
3 Destination Unreachable 0 Netzwerk nicht erreichbar
1 Host (Zielstation) nicht erreichbar
2 Protokoll nicht erreichbar
3 Port nicht erreichbar
4 Fragmentierung nötig, Don’t Fragment 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
5 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
11 Time Exceeded 0 TTL (Time To Live, Lebensdauer) abgelaufen
1 Zeitlimit während der Defragmentierung überschritten

Daten[Bearbeiten | Quelltext bearbeiten]

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, einen unterschiedlichen Inhalt und sind verschieden strukturiert

  • Oft wird der IP-Header wiederholt und im Anschluss daran die ersten 64 Bit des ursprünglichen Datagramms
  • Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht

Anwendung[Bearbeiten | Quelltext bearbeiten]

Erreichbarkeit prüfen ping
Weg nachvollziehen traceroute
Maximale Path-MTU ermitteln Path MTU Discovery
Umleitung im Netzwerk IPv4/ICMP/Redirect


Anhang[Bearbeiten | Quelltext bearbeiten]

Siehe auch[Bearbeiten | Quelltext bearbeiten]


Dokumentation[Bearbeiten | Quelltext bearbeiten]

RFC[Bearbeiten | Quelltext bearbeiten]
  1. https://tools.ietf.org/html/rfc792

Links[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]