Internet Control Message Protocol: Unterschied zwischen den Versionen
| Zeile 24: | Zeile 24: | ||
*erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen | *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 | *besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe | ||
Die ersten vier Bytes des Headers haben ein festgelegtes Format, | 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]] | [[Datei:ICMP3.png|800px|ohne]] | ||
Version vom 2. März 2021, 11:27 Uhr
Das Internet Control Message Protocol (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 RFC 777
- mehrmalige Aktualisierungen führten zur aktuellen Definition 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.
| Typ | Typname | Code | Bedeutung |
|---|---|---|---|
| 0 | Echo-Antwort | 0 | Echo-Antwort |
| 3 | Ziel nicht erreichbar | 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 | Entlasten der Quelle | 0 | Datagramm verworfen, da Warteschlange voll |
| 8 | Echo-Anfrage | 0 | Echo-Anfrage (Ping) |
| 11 | 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