IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Protokolle - Internet Control Message Protocol



Internet Control Message Protocol

Da IP bezüglich der Datenübertragung sehr unzuverlässig ist, muss es eine Möglichkeit geben, gewisse Fehler aufzudecken. Hierzu dient ICMP.


Autor: Martin Puaschitz (onestone)
Datum: 23-01-2002, 19:06:09
Referenzen: Hall, Eric. A - Internet Core Protocols; O'Reily 2000
Schwierigkeit: Fortgeschrittene
Ansichten: 6053x
Rating: 8 (1x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



3

1.Einleitung

Es ist ja bekannt, dass IP, was die Datenübertragung angeht, sehr unzuverlässig ist. Es kann also ohne weiteres geschehen, dass Datenpakete verloren gehen, ohne dass IP etwas dagegen unternimmt. Höhere Protokolle wie TCP bemerken diesen Verlust und wenden verschiedene Schritte an, um die verlorengegangenen Pakete erneut zu übertragen.

Doch was geschieht, wenn kein einziges Datagramm das Ziel erreicht? Hier sollte der Sender in irgendeiner Form verständigt werden, um entweder das weitere Senden von Daten in diese Richtung zu beenden oder eine alternative Route zu suchen. Diese Fehler werden „non-transient errors“ genannt. Um diesen Problemen entgegenzuwirken, verwendet IP ICMP.

1.1. Die Spezifikation

ICMP wurde in RFC 792 festgelegt und ist mittlerweile Teil von STD 5 und somit ein Internet Standard Protokoll. Die Protocol ID für ICMP ist 1. Wenn ein System ein IP-Datagramm mit der Protocol ID 1 empfängt, muss es das Paket sofort an das lokale ICMP Service weiterreichen.

ICMP ist kein Transportservice für Daten. ICMP ist ein Kontroll-Protokoll wie IGMP welches über Änderungen und Ereignisse der Netzwerke informiert. ICMP wird von IP immer verwendet, wenn Probleme auftreten. IP und ICMP sind stark verwachsen und aus diesem Grund ist es unumgänglich, dass jede IP Implementation auch ICMP beinhaltet.

1.2. Warum ICMP so wichtig ist

Das Internet Protocol ist bekanntlich ja nur dafür zuständig einzelne Pakete nacheinander zu übertragen. Hier kann es oft geschehen, dass diese Pakete verloren gehen. Hierfür gibt es verschiedenste Gründe wie eine plötzlich gekappte Leitung zwischen zwei Routern oder eine nicht existente IP-Adresse. In jedem Fall wird das Gerät, in dem sich das entsprechende Paket gerade befindet, dieses löschen und sich einfach dem nächsten Paket zuwenden.

Ob nun eine ICMP Nachricht an den ursprünglichen Sender geschickt wird, hängt vom jeweiligen Fehler ab. Normalerweise beruht diese Entscheidung darauf, ob der jeweilige Fehler Transient oder Semi-Permanent ist.

Transiente Fehler sind z.B. nicht korrekte Checksummen. Diese werden gänzlich ignoriert, da angenommen wird, dass das sendende System den Verlust bemerken wird. Die Annahme hierbei ist, dass wichtige Daten meist über verlässliche Protokolle gesendet werden (z.B. TCP). Da dies hier nicht der Fall ist, scheinen die Daten dementsprechend unwichtig. In weiterer Folge wird auch angenommen, dass weitere Pakete nicht dieselben Probleme oder Fehler beinhalten werden. Bei Transienten Problemen scheint der Fehler nur im jeweiligen Paket zu liegen und nicht etwa in der Netzwerkstruktur.

Im Gegenzug müssen Semi-Permanente Fehler (z.B. eine ungültige IP-Adresse) via ICMP sofort an den Sender übermittelt werden, da diese Fehler grundlegende Probleme der Netzwerkstruktur aufweisen. Somit wird der Sender aufgefordert Pakete mit dieser Konfiguration (z.B. der ungültigen IP-Adresse) zu unterlassen oder entsprechende Modifikationen durchzuführen damit eine Weiterleitung der Pakete möglich wird.

Von Semi-Permanenten „Fehlern“ spricht man unter anderem, dann, wenn die Destination nicht erreichbar ist, oder wenn das TTL-Feld Null erreicht und so weiter. Des weiteren sind diese Fehler für verschiedene Diagnoseprogramme sehr interessant da dies Aussagen über die Netzwerkstruktur macht. Das wohl bekannteste Programm ist „ping“, welches ICMP Nachrichten für seine Aussagen verwendet.

ICMP ist im eigentlichen Sinne kein intelligentes Protokoll sondern ein Katalog von Fehlermeldungen. Das System, wo der Fehler auftritt, nimmt nur die passende Nachricht, verpackt diese in ein ICMP Paket und sendet sie an den Absender des fehlerhaften Paketes zurück.

Sobald das System diese ICMP Nachricht erhält, leitet IP das Datagramm an ICMP weiter (IP ordnet dies nach dem Protocol Identifier zu). ICMP liest nun den Inhalt des Datagramms und leitet die jeweilige Fehlermeldung an höherstehende Protokolle weiter. Falls die Nachricht allerdings direkt für ICMP bestimmt ist, (ein Beispiel ist hier ein echo-request) antwortet ICMP selbst und bezieht keine anderen Protokolle in die Entscheidungen ein.

1.3. Wann keine ICMP Nachrichten gesendet werden

Es ist wohl genauso wichtig zu wissen wann ICMP Nachrichten nicht gesendet werden sollen oder dürfen. Dies ist vor allem wichtig, da ICMP laut RFC 1122 keinen exzessiven Datentransfer in einem Netzwerk verursachen darf. Folgende Regeln beziehen sich darauf, wann keine Antworten via ICMP versendet werden dürfen.

· Wenn eine ICMP-Nachricht empfangen wird (dies ist dennoch für verschiedene administrative Zecke möglich).

· Wenn eine IGMP-Nachricht empfangen wird.

· Wenn ein IP-Datagramm mit einer IP-Adresse für eine Broadcast- oder Multicastadresse empfangen wird.

· Wenn ein IP-Datagramm mit keiner spezifizierten Absenderadresse empfangen wird.

· Wenn ein Data-Link-Frame mit einer Broadcast- oder Multicastadresse empfangen wird.

· Wenn irgendein Fragment – mit Ausnahme des ersten – empfangen wird.

Die erste Regel ist nur optional. Das Problem hierbei liegt darin, dass Antworten auf Antworten eine Endlosschleife bilden und ein gesamtes Netzwerk vollständig blockieren können. Dennoch wird dies nicht unterbunden da verschiedene Router in manchen Fällen dennoch mit ICMP-Nachrichten auf gewisse Fehler antworten.

Der Grund, warum Systeme keine ICMP-Nachrichten als Antwort auf Broadcast- oder Multicastadressen schicken sollen, ist dass, damit der Netzwerkverkehr auf ein Minimum beschränkt ist. Ein Beispiel: Wenn ein System einen UDP-Broadcast an alle Rechner in seinem lokalen Segment sendet, aber nur einige wenige Rechner die entsprechende Applikation gestartet haben, würde jeder andere Rechner mit einer „Destination Port Unreachable“ Nachricht antworten. In einem großen Netzwerk können diese Nachrichten kurzzeitig alle Netzwerkstrecken blockieren.

Ebenso ist es mit der letzten Regel. Wenn ein Datagramm in zehn verschiedene Pakete zerlegt wird, würden bei einem Netzwerkproblem zehn ICMP-Nachrichten an den ursprünglichen Sender geschickt werden. ICMP löst dieses Problem, indem nur für das erste Fragment eine Fehlermeldung geschickt wird (da das Datagramm ja auch nicht vollständig übertragen wurde, wenn nur dieser Teil fehlt).

1.4. Zustellungsprobleme

Wie schon oft erwähnt, ist IP unzuverlässig und ICMP versucht das sendende System auf verschiedene Fehler aufmerksam zu MAChen. Hier gibt es eine Reihe von verschiedenen Fehlermöglichkeiten, die vor allem für UDP sehr wichtig sind. UDP hat ja selbst keine Fehlerkontrolle und verlässt sich daher vollständig auf IP und natürlich ICMP.

1.4.1. Destination Unreachable error messages

Diese Nachrichten können aufgrund von verschiedensten Problemen verschickt werden. Es könnte z.B. sein, dass ein Router keinen Pfad zu dem entsprechenden System finden kann oder dass ein Port auf dem System des Empfängers nicht verfügbar ist. Aus diesem Grund gibt es bei dieser Fehlermeldung mehrere Fehlermeldungsmöglichkeiten:

Network Unreachable

Diese Nachricht bedeutet, dass der entsprechende Router keine Route zum Zielnetzwerk finden kann. Als Beispiel dient Grafik 3.9. Hier versucht Ferret ein IP-Datagramm an 192.168.30.10 zu senden. Seine default-route zeigt auf Sasquatch, welcher aber selbst keinen Routingeintrag zu dem Netzwerk 192.168.30 hat, deshalb schickt er eine ICMP Nachricht an Ferret zurück.

Grafik 3.9

Wichtig anzumerken ist, dass diese Nachricht von jedem Router zwischen Sender und Empfänger gesendet werden kann.

Host Unreachable

Diese Nachricht wird vom letzten zuständigen Router vor einem Rechner erstellt, wenn der entsprechende Rechner nicht erreichbar ist. Dies muss nicht heißen, dass der Rechner nicht existiert, sondern nur, dass derzeit keine Verbindung möglich ist.

Protocol Unreachable

Sobald das sendende System ein Non-Standard-Protokoll verwendet, kann es vorkommen, dass der Empfänger dies nicht unterstützt. Dann wird diese Nachricht an den Sender zurückgesendet.

Port Unreachable

Es kann durchaus vorkommen, dass ein System (z.B. Ferret) einen Dienst nicht gestartet hat oder diesen nicht verwendet. Wenn also ein weiteres System (z.B. Fungi) bei Ferret auf einen bestimmten Port zugreifen möchte, dieser aber nicht erreichbar ist, sendet Ferret eine Port Unreachable Nachricht via ICMP an Fungi.

Fragmentation Required but DF Bit Is Set

Sobald das sendende System Ferret die DF-Flag (Don’t Fragment) aktiviert hat, die MTU auf dem Weg zum Empfänger allerdings eine Fragmentierung notwendig machen würde, wird diese Nachricht an Ferret gesendet. Da für den Netzwerktyp, über welche dieses Datagramm gesendet werden muss, die Übertragung als ganzes nicht ermöglicht (MTU zu klein), müsste das Datagramm fragmentiert werden. Da aber die DF-Flag gesetzt wurde, ist dies nicht möglich.

Source Route Failed

Diese Nachricht bedeutet, dass der Router das Paket zu dem nächsten Router laut Source Route IP Option nicht zustellen kann, weil dieser nicht verfügbar ist.

Destination Network Unknown

Diese Nachricht bedeutet, dass das angegebene Zielnetzwerk nicht existiert. Im Gegenzug zu Network Unreachable - wo nur angegeben wird, dass das Zielnetzwerk nicht erreichbar ist - kann bei dieser Meldung eindeutig festgestellt werden, dass das Netzwerk nicht existiert.

Destination Host Unknown

Hier gilt das gleiche Prinzip wie bei Destination Network Unknown, nur für den entgültigen Host. Auch hier kann eindeutig festgestellt werden, dass der angegebene Host nicht existiert.

Network Unreachable for Type-of-Service

Diese Nachricht wird von Routern zwischen dem Sender und Empfänger versendet, sobald das nachfolgende Netzwerk den gewünschten Type-of-Service nicht mehr unterstützt. Wenn keine andere Route mit passender Type-of-Service Unterstützung möglich ist, löscht der entsprechende Router das Paket und sendet diese Fehlermeldung an den ursprünglichen Absender.

Host Unreachable for Type-of-Service

Hier gilt das selbe Prinzip wie bei Network Unreachable for Type-of-Service, nur dass hier der Zielrechner selbst den gewünschten Type-of-Service nicht unterstützt.

Communication Administratively Prohibited

Diese Nachricht wird dann versendet, wenn der Zugriff auf ein Netzwerk, in welchem der Zielrechner liegt, vom Administrator gesperrt wurde. Dies kann durch eine Firewall geschehen, von der alle Pakete in ein bestimmtes Netz abgewiesen werden.

Oft unterbinden die Administratoren allerdings die Ausgabe dieser ICMP Nachricht, da potentielle Angreifer somit leicht herausfinden können, welche Rechner besonders geschützt werden. Hier ist es besser, Pakete einfach zu löschen.

Host Precedence Violation

Bei dieser Fehlermeldung hat der Sender eine vorrangige Variable innerhalb des IP-Paketes gesetzt, die vom Empfänger, vom Empfängernetzwerk oder von der Empfängerapplikation nicht unterstützt wird. Sobald der Sender diese Fehlermeldung erhält, muss er seine Angaben überprüfen und das Paket erneut senden.

Host Precedence Violation-precedence Cutoff in Effect

Diese Fehlermeldung ist ähnlich der Host Precedence Violation. Hier wird zwar das Kriterium der vorrangigen Variable erfüllt, allerdings reicht dies nicht aus – es kann z.B. sein, dass die Zahl nicht entsprechend gesetzt ist, etc. Diese Einrichtung ist meist bei sehr teuren Netzwerken der Fall. Kann der Sender das Paket nicht dementsprechend abändern, muss er eine andere Route finden.

1.4.2. Time Exceeded error messages

Sobald ein Reassembly nach einer Fragmentierung oder eine Weiterleitung zu lange dauert, tritt ein Timeout-Fehler auf. Wenn dies eintritt, löscht der entsprechende Router das Paket und sendet diese ICMP-Nachricht an den Sender zurück. Es gibt allerdings zwei verschiedene Typen dieser Fehler:

Time-to-Live Exceeded in Transit

Wenn diese Nachricht auftritt, konnte ein IP-Paket nicht zugestellt werden, da das TTL Feld innerhalb des Headers null erreicht hat, bevor es den Empfänger erreicht hat. In den meisten Fällen wird diese Meldung durch ein Routing-loop verursacht.

Fragment Reassembly Time Exceeded

Wenn ein System nicht alle Fragmente eines Datagrammes innerhalb einer gewissen Zeitspanne erhält (viele UNIX-Systeme verwenden hier 60 Sekunden), werden alle Fragmente gelöscht und diese ICMP-Nachricht an den Sender zurückgesendet.

1.4.3. Redirect error messages

Diese Nachrichten werden versendet, sobald ein Router es für wichtig hält, einen Sender über einen kürzeren Weg zu einer speziellen Destination zu informieren. Eine Grundregel hierfür ist, dass beide Router und der Sender im gleichen Subnetz liegen.

Die Grafik 3.10 zeigt Ferret (192.168.10.10), welcher versucht ein Datagramm für 192.168.30.10 an Sasquatch zu senden. Sasquatch bemerkt, dass es sinnvoller wäre, wenn Ferret seine Daten an 192.168.30.10 über Canary senden würde. Aus diesem Grund sendet Sasquatch eine Redirect error message an Ferret.

Anzumerken ist allerdings, dass Sasquatch dennoch das erhaltene Paket an Canary weiterleitet; weitere Pakete sollte Ferret aber über Canary senden.

Grafik 3.10

Um detailliertere Informationen auszugeben, hat auch diese ICMP-Nachricht vier Möglichkeiten der genaueren Spezifikation:

Redirect for Destination Network

Diese Nachricht wird verwendet, wenn jegliche Daten für das entsprechende Zielnetzwerk über einen anderen Router gesendet werden sollten.

Redirect for Destination Host

Diese Nachricht hingegen wird verwendet, wenn jegliche Daten für einen speziellen Zielrechner über einen anderen Router gesendet werden sollten.

Redirect for Destination Network Based on Type-of-Service

Für den Fall, dass der Sender ein gewisses Type-of-Service verlangt, dies aber von einem Router nicht unterstützt wird, sendet dieser Router diese ICMP-Nachricht und verständigt den Sender über einen alternativen Router, über welchen der Type-of-Service unterstützt wird.

Redirect for Destination Host Based und Type-of-Service

Ähnlich wie Redirect for Destination Network Based on Type-of-Service ist auch diese ICMP-Nachricht – allerdings nur für einen bestimmten Zielrechner.

1.4.4. Source Quench error messages

Die Source Quench error messages sind wohl die simpelsten Nachrichten bei ICMP. Sobald ein Rechner zu viele Daten von einem anderen System empfängt, sendet er diese ICMP-Nachricht an den jeweiligen Sender. Der Sender muss aufgrund dieser Nachricht seinen Datenstrom reduzieren, ansonsten werden eingehende Pakete beim Empfängersystem gelöscht.

1.4.5. Parameter Problem error messages

Bei dieser ICMP-Nachricht wird generell ein Problem mit dem IP-Datagramm selbst beschrieben. Sobald dies auftritt, wird das Datagramm gelöscht und diese Fehlermeldung an den ursprünglichen Sender geschickt. Auch hier gibt es verschiedene Unterscheidungsmöglichkeiten:

Pointer Indicates the Error

Dieser Fehler bedeutet, dass ein spezieller Fehler mit der Struktur des Datagrammes vorliegt. Die fehlerhafte Stelle ist innerhalb der ICMP Nachricht festgehalten, damit der ursprüngliche Sender selbst die Ursache des Fehlers überprüfen kann.

Required Option Is Missing

Dieser Fehler bedeutet, dass eine benötigte IP-Option nicht definiert wurde. Da dies allerdings meist nur in Zusammenhang mit Sicherheit innerhalb des Amerikanischen Militärs verwendet wird, können wir es vernachlässigen.

Bad Length

Bei dieser Fehlermeldung scheint die Länge des Headers oder die gesamte Paket-Größe nicht korrekt zu sein.

1.5. Netzwerktests

ICMP hat großartige Eigenschaften für Netzwerktests. Da die Fehlerbeschreibungen detailliert und aufschlussreich sind, kann ein Netzwerkadministrator sehr einfach Fehler finden oder gängige Konfigurationen testen.

1.5.1. Echo Request und Echo Reply Nachrichten

Das wohl am häufigsten verwendete Programm ist ping. Es ist beinahe auf jedem System installiert und ermöglich die Anfrage, ob ein Zielrechner online ist, oder nicht.

ICMP stellt für dieses Programm zwei Module zur Verfügung. Der Echo Request (ping) sendet eine Anfrage an ein System. Dieses System muss mit einem Echo Reply (pong) antworten. Da in RFC 1122 festgelegt wurde, dass jedes System einen ICMP Echo Reply Server implementiert haben muss, ist dieses Service sehr zuverlässig.

Es gibt sehr viele verschiedene Versionen des Programms ping. Bei den gängigsten unter Windows oder Linux, ist es möglich verschiedene Optionen und Netzwerkeigenschaften durch Hinzufügen von Optionsfeldern zu testen.

Mit einem einfachen ping ist es somit möglich, den Pfad eines Paketes von A nach B zu verfolgen, die maximale MTU eines Netzwerkes festzustellen oder alle Rechner in einem lokalen Segment zu erreichen (Broadcast). Die gängigste Option ist, die Zeit zwischen ping und pong zu messen, um die Netzwerkauslastung zu überprüfen.

1.5.2. Timestamp Request und Timestamp Reply query Nachrichten

Im Vergleich zu ping ist diese Methode noch effizienter, als nur die Zeit zwischen ping und pong zu messen, da hier auch jene Zeit einberechnet wird, welche die Systeme für die ICMP Nachricht selbst aufbringen müssen.

Der Nachteil dieser Zeitmessung ist allerdings, dass Timestamp Request und Reply nicht unbedingt in jedem System implementiert sein müssen und dass die Uhrzeiten beider Systeme zuerst synchronisiert werden müssen (z.B. via NTP).

Das Vorgehen bei dieser Variante ist simpel. Der Befehl Timestamp Request sendet ein Paket – in dem die aktuelle Zeit des Sendesystems eingetragen ist – an das jeweilige System und bittet um eine Zeiteintragung dieses Systems. Sobald das Timestamp Reply beim ursprünglichen Sender wieder angekommen ist, kann dieses die Zeiten vergleichen und somit genau errechnen, wie lange der Vorgang gedauert hat.

Sie werden sich vielleicht fragen, wie dies innerhalb des Internets und der verschiedenen Zeitzonen weltweit möglich ist. Hier verwenden alle Systeme UTC (Universal Time), welche die Sekunden von Mitternacht an zählt. Somit liegen alle Systeme immer in der selben Zeitzone.

1.5.3. Address Mask Request und Address Mask Reply query Nachrichten

Diese Option wird nur von wenigen Geräten unterstützt, kann aber durchaus sinnvoll sein. Sobald ein System nur via Bootdiskette gestartet wird (was früher oft gang und gäbe war) aber eine gültige IP-Adresse benötigt, wird diese über Protokolle wie Reverse ARP, BOOTP oder DHCP zugeteilt.

Hierbei erhält das System allerdings keine Subnetmask. Um diese zu erlangen sendet es einen Adress Mask Request an 255.255.255.255. Nun sollte ein Adress Mask Server ein Adress Mask Reply query an den Rechner schicken, in welchem die gültige Subnetmask eingetragen ist.

1.5.4. Router Solicitation und Router Advertisement query Nachrichten

Dieses Konzept wurde entwickelt, um das Router Discovery Protocol zu definieren. Dadurch ist es möglich, dass alle Systeme in einem Netzwerk via ICMP query Nachrichten ihre Routing-Tabellen anpassen oder/und aktualisieren.

Das Router Discovery Protocol beinhaltet die Router Solicitation query message, welche von Systemen an 224.0.0.2 (all-Routers) gesendet wird. Jeder Router in diesem Netzwerk sollte dann mit einem Router Advertisement antworten.

Jedes Router Advertisement beinhaltet eine Präferenz-Wert für den jeweiligen Router. Systeme tragen den Router mit dem niedrigsten Präferenz-Wert als ihren Default-Router ein.

Dieses Beispiel ist in Grafik 3.11 dargestellt. Ferret sendet eine ICMP Router Solicitation query Nachricht an die all-Routers Multicast Gruppe (224.0.0.2). Daraufhin antworten Sasquatch und Canary mit einem Router Advertisement und geben jeweils ihren Präferenz-Wert an. Dadurch (da die Router unterschiedliche Werte in ihren Advertisements mitsenden) hat Sasquatch die höhere Priorität (da den niedrigeren Wert) und wird deshalb der Default-Router von Ferret.

Grafik 3.11

Wichtig ist allerdings, dass die Router nicht selbst Ihre Netzwerkverbindungen anzeigen, sondern dies von den einzelnen Systemen ausfindig gemacht werden muss. Sobald der Default-Router bemerkt, dass ein anderer Router für gewisse Netzwerke besser geeignet ist, er allerdings diese Pakete dennoch erhält, sendet er eine Redirect error message an den Sender, damit dieser seinen Routing-table dementsprechend anpassen kann und Pakete in dieses bestimmte Zielnetz auch über den geeigneteren Router schickt. Für alle anderen Zielnetze verwendet der Sender weiterhin seinen Default-Router, solange bis dieser ihm eine sinnvolleren Router vorschlägt.

1.6. ICMP Nachrichten

Die folgende Tabelle zeigt die wichtigsten Nachrichten-Typen von ICMP in Verwendung mit IPv4 an:

Type

Beschreibung

Nachrichtentyp

Definiert in

0

Echo Reply

Query (Reply)

RFC 792

3

Destination Unreachable

Error



[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06243
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1144
Comments: 0