Zurück zum Inhaltsverzeichnis des Manuskripts verteilte Systeme

5.5 Internet Control Message Protocol

Aufgabe

Weder IPv4 noch IPv6 stellen eine Möglichkeit zur Verfügung, dem Sender eines IP-Pakets neben den Nutzdaten noch eine Nachricht zukommen zu lassen. Dabei könnte es sich beispielsweise um Hinweise über Fehler handeln, die bei einer Übertragung oder bei dem Versuch einer Übertragung aufgetreten sind. Angenommen, auf dem Zielrechner existiert die Zielanwendung für ein bestimmtes IP-Paket gar nicht, dann scheitert der Kommunikationsversuch. Über diesen Sachverhalt muss der Sender informiert werden. Aber es sind nicht nur Fehlerhinweise, die zu kommunizieren sind. Man denke an den Fall, dass ein Router durch Herunterzählen des TTL-Feldes bei IPv4 bzw. des Hop-Limit-Feldes bei IPv6 im IP-Header den Wert 0 erreicht und das Paket verworfen hat. Er muss jetzt den Absender dieses Pakets über diesen Sachverhalt verständigen.

Für die Übermittlung solcher Nachrichten ist ein eigenes DoD-2- (bzw. OSI-3-) Protokoll mit dem Namen Internet Control Message Protocol (ICMP) entwickelt worden. Es wird mit den Bezeichnungen ICMPv4 bzw. ICMPv6 bei beiden IP-Versionen eingesetzt. ICMP benutzt IP als Transportmittel, indem es sich selbst als Protokoll einer höheren Protokollschicht interpretiert. Das heißt, dass ICMP-Nachrichten in IP-Paketen gekapselt werden. Tritt zum Beispiel der gerade beschriebene Fall auf, dass eine Anwendung auf dem Zielrechner für ein IP-Paket nicht erreichbar ist, dann sendet die IP-Station auf dem Zielrechner der IP-Station auf dem Quellrechner ein ICMP-Paket mit der Nachricht Ziel nicht erreichbar. Hat ein Router ein IP-Paket verworfen, weil dessen Lebensdauer abgelaufen ist, dann sendet er dem Sender des verworfenen Pakets ein ICMP-Paket mit der Nachricht Zeitüberschreitung. Welche Nachrichten es gibt und wie sie kodiert werden, wird im nächsten Absatz erläutert.

ICMP-Pakete

ICMP-Pakete sind klassisch aufgebaut und beginnen mit einem Protokollkopf, dem ein Datenteil folgt. Es soll hier genügen, den Aufbau eines ICMP-Pakets am Beispiel von ICMPv4 zu erläutern. Der Protokollkopf beginnt immer mit einer Folge von drei Feldern, die zusammen vier Bytes belegen und folgende Bedeutungen haben:

Das erste Feld, also der Typ, kodiert die Nachricht, während das zweite Feld (der Code) diese Nachricht gegebenenfalls verfeinert. Das Protokoll weist über 200 Typen aus, von denen die meisten allerdings nicht belegt sind. Oft benutzt werden:

Als Beispiel für eine Nachrichtenverfeinerung kann der Typ 3 herangezogen werden:

Das dritte und letzte Feld des ICMP-Protokollkopfs enthält eine zwei Bytes große Prüfsumme, die sich über das gesamte ICMP-Paket erstreckt. Die folgende Grafik veranschaulicht den Aufbau eines ICMP-Pakets und weist einige typische Werte der Felder Typ und Code aus:

ICMP-Header

Die beiden Nachrichten vom Typ 8 und 0 zeigen, dass ICMP benutzt werden kann, um die Erreichbarkeit einer IP-Station mit darin enthaltener ICMP-Station auf einem Zielrechner per Echo-Anfrage zu ermitteln. Wie ein ICMP-Paket nach seinem Protokollkopf weiter aufgebaut ist, hängt von der jeweiligen Meldung ab, die transportiert werden soll. Ist es eine Fehlermeldung, dann wird der IP-Protokollkopf des fehlerverursachenden Pakets samt seiner ersten 64 Datenbits angefügt. Bei einer Echo-Anfrage wird in die auf die ersten vier Bytes folgenden zwei Bytes eine Kennung für die sendende Anwendung eingetragen, denn Ports stehen für ICMP nicht zur Verfügung.

ICMP-Anwendung ping

Zu dem ICMP-Echo-Verfahren gibt es eine Kommandoschnittstelle. Das Kommando wird in Anlehnung an das Geräusch eines Sonars bei einem Treffer ping genannt. Es sendet je nach Parametrisierung mindestens eine Echo-Anforderung an einen Zielhost und setzt einen Timeout. Ist dieser abgelaufen ohne dass eine Antwort vorliegt, wird der Zielhost als nicht erreichbar bezeichnet. Mit dem ping-Kommando steht ein sehr einfaches Werkzeug für eine Netzwerkdiagnose zur Verfügung. Allerdings ist zu beachten, dass ein ungünstiges zeitliches Verhalten im Netzwerk oder Sicherheitssoftware auf dem Zielrechner die Diagnosefähigkeit einschränken.

Das ping-Kommando gibt es in mehreren Ausprägungen. Es ist deshalb angebracht, auf dem lokalen System zunächst die lokale Dokumentation zu studieren. Es folgt ein Beispiel, das im Herbst 2018 auf meinem Rechner an unserer Hochschule gestartet worden ist:

ping hrz hrz is alive

Angesprochen wurde der Rechner hrz.bht-berlin.de. Seine im IP-System enthaltene ICMP-Station hat die Echo-Anfrage meiner ICMP-Station beantwortet. Ist die Echo-Anfrage nach einer voreingestellten aber parametrisierbaren Zeitspanne, im vorliegenden Fall nach 20 Sekunden, noch nicht beantwortet, dann meldet das ping-Kommando:

ping hrz no answer from hrz

Manchmal ist es nützlich, das ICMP-Echo-Verfahren eingebettet in eine Programmiersprache zu benutzen. Am Beispiel Java sieht das folgendermaßen aus:

import java.net.*; class Ping { public static void main(String[] unused) throws Exception { String ziel = "www.tu-berlin.de"; InetAddress addr = InetAddress.getByName(ziel); if(addr.isReachable(60)) System.out.println("Host "+ziel+" erreichbar"); else System.out.println(ziel+" nicht erreichbar"); } }

Mit dem Programm wird mit Hilfe der Methode boolean isReachable(int timeout) aus der Klasse InetAddress im Paket java.net ein ICMP-Echo-Request gesendet und 60 Millisekunden auf eine Antwort gewartet.

ICMP-Anwendung traceroute (tracert)

Ein weiteres elementares Netzwerk-Diagnose-Werkzeug auf der Basis von ICMP ist ein Shellkommando, das in der Unix/Linux-Welt traceroute und in der Windows-Welt tracert heißt. Es verwendet das TTL-Feld aus dem IPv4-Header bzw. das Hop-Limit-Feld aus dem IPv6-Header und nutzt aus, dass jeder Router, den ein IP-Paket erreicht, den Wert dieses Felds um 1 verringert, beim Erreichen des Wertes 0 das zugehörige Paket verwirft und darüber per ICMP-Nachricht (Typ=11) den Absender verständigt.

Das Kommando bildet IP-Pakete, die nur aus einem Protokollkopf bestehen, und verändert den Wert des TTL- bzw. des Hop-Limit-Felds systematisch. Es beginnt mit dem Wert 1, erzeugt drei Pakete mit diesem Wert und sendet sie an eine bestimmte Adresse. Die Folge ist, dass der erste Router, den diese Pakete erreichen, den Wert auf 0 setzt, die Pakete verwirft und den Absender verständigt. Dann erhöht das Kommando den Wert des TTL- bzw. Hop-Limit-Feldes auf 2, bildet wieder drei Pakete und schickt diese an die gleiche Adresse wie vorher. Jetzt wird der zweite Router die Pakete verwerfen und dies melden, usw. Damit auch der Zielrechner selbst zu einer Fehlermeldung provoziert wird, wird durch das Paket eine Anwendung mit einem unmöglichen Port adressiert. Benutzt wird dafür eine extrem hohe Portnummer, zu der es mit großer Wahrscheinlichkeit keine Anwendung gibt. Der Empfänger reagiert dann mit einem ICMP-Paket mit der Meldung Port nicht erreichbar (Typ=3; Code=3).

Durch dieses Vorgehen entsteht durch die Folge der ICMP-Antworten eine Fährte (ein Trace) der Pakete durch das Netzwerk bis hin zum Empfänger. Sie ist etwas verwaschen, weil unterschiedliche Pakete unterschiedliche Wege nehmen können. Wie schon das ping-Kommando liegt auch das traceroute- bzw. tracert-Kommando in verschiedenen Ausprägungen vor, so dass auch hier vor einer Verwendung die lokale Dokumentation herangezogen werden sollte. Der folgende Kommandoaufruf wurde im Herbst 2018 auf meinem Rechner an der Hochschule gestartet. Er zeigt eine Fährte vom Wedding in Berlin zu dem Webserver des World-Wide-Web-Konsortiums: (In der folgenden Kommandoausgabe sind lediglich die waagrechten Trennstriche aus optischen Gründen im Nachhinein hinzugefügt worden.)

traceroute www.w3.com rou890-224.tfh-berlin.de (141.64.89.1) 0.706 ms 0.462 ms 0.409 ms phrz.tfh-berlin.de (141.64.224.11) 1.107 ms 1.094 ms 1.078 ms 141.64.225.1 (141.64.225.1) 1.641 ms 1.550 ms 2.218 ms ssr8000.tfh-berlin.de (141.64.0.1) 2.164 ms 1.778 ms 1.886 ms ----------------------------------------------------------------------------------- ar-tuberlin1.g-win.dfn.de (188.1.33.65) 2.368 ms 2.394 ms 2.565 ms cr-berlin1.g-win.dfn.de (188.1.20.9) 2.931 ms 2.684 ms 2.407 ms cr-frankfurt1.g-win.dfn.de (188.1.18.21) 11.365 ms 11.274 ms 11.042 ms ----------------------------------------------------------------------------------- so-6-0-0.ar2.FRA2.gblx.net (208.48.23.141) 11.764 ms 11.241 ms 11.229 ms pos5-0-2488M.cr2.FRA2.gblx.net (62.16.32.77) 11.524 ms 11.358 ms 11.569 ms pos2-0-2488m.cr2.CHI1.gblx.net (208.49.59.254) 121.778 ms 121.414 ms 121.740 ms 208.49.59.210 (208.49.59.210) 135.718 ms 141.504 ms 121.597 ms p3-2.edge.chi-il.us.xo.net (207.88.50.241) 122.248 ms 121.872 ms 121.729 ms ge5-3-1.RAR1.Chicago-IL.us.xo.net (64.220.0.189) 122.507 ms 160.062 ms 122.417 ms p0-0-0-1.RAR2.Chicago-IL.us.xo.net (65.106.1.90) 122.780 ms 122.927 ms 129.865 ms ----------------------------------------------------------------------------------- p6-0-0.RAR1.NYC-NY.us.xo.net (65.106.0.30) 154.233 ms * 153.896 ms p3-0.DCR1.DC-Secaucus-NJ.us.xo.net (65.106.2.130) 154.743 ms 154.584 ms 154.400 ms 64.35.127.163 (64.35.127.163) 156.957 ms 149.618 ms 149.640 ms w3.com (216.22.248.204) 149.658 ms 153.419 ms 150.087 ms

Ein Sternchen in der Ausgabe bedeutet, dass es auf das zugehörige IP-Paket in der vorgegeben Wartezeit keine Antwort gegeben hat. Die sichtbar gewordene Fährte führt über die TU-Berlin nach Frankfurt/Main, von dort ohne Zwischenstopp (per Satellit) nach Chicago und endet schließlich in New York City.



Zurück zum Inhaltsverzeichnis des Manuskripts verteilte Systeme