Diskussion:Internet Control Message Protocol

Schicht-Einordnung

Zitat: Obwohl ICMP eine Ebene über IP angeordnet ist (im OSI-Modell die so genannte Vermittlungsschicht (Network Layer)), ist es in IP integriert. -- Das ist Falsch, ICMP und IP sind beide auf Layer 3 anzufinden! -- (Vorstehender nicht signierter Beitrag stammt von 84.169.20.39 (Diskussion • Beiträge) 2006-01-19T15:55:42)

Man sieht es aber oft auch auf dem Transport-Layer. ICMP benutzt ja keines der Transportprookolle wie z.b. TCP oder UDP. -- (Vorstehender nicht signierter Beitrag stammt von Vuk3k (Diskussion • Beiträge) 2006-05-14T11:44:35)

Unter dem Artikel ueber das OSI-Modell steht es auch auf Layer 3, ebenso in der englischen wikipedia. Man sollte sich da moeglichst auf eine einheitliche Aussage einigen, oder dazuschreiben, dass es nicht wirklcih einzusortieren ist. -- (Vorstehender nicht signierter Beitrag stammt von 129.13.186.3 (Diskussion • Beiträge) 2006-09-04T19:18:15)

Ich denke NICHT, dass man sich darauf EINIGEN sollte, was richtig ist und was falsch. Und falsche Fakten als wahr zu nehmen, nur weil sie woanders auch so stehen, halte ich für gefährlich. Desweiteren ist ICMP im Beitrag über das Internet_Protocol auch auf Layer 4 angeordnet. Warum sich also nicht diese Lösung einigen? (-- 87.78.75.94 21:02, 14. Mai 2007 (CEST))

Ich bin deutlich dafür, dazuzuschreiben, daß es eben nicht genau einzuordnen ist - finde es so wie es ist aber sonst logisch: Aus Sicht des ISO/OSI-Modells ist es OK auf der Vermittlungsschicht, einfach weil es logisch zu den Aufgaben der Vermittlungsschicht gehört; aus IP-Sicht ist es aber natürlich einfach ein quasi beliebiges Protokoll der nächst höheren Schicht und wird genauso transportiert etc. wie TCP oder UDP. Es ist also beides zu rechtfertigen und insofern sollte man hier IMHO nicht eine zu klare Einordnung vornehmen.

Außerdem ist die Bezeichnung "Netzwerk" irreführend, es heißt entweder "Network" (englisch, sollte man hier natürlich vermeiden) oder "Vermittlung" (ISO/OSI) oder "Internetschicht" (TCP/IP-Referenzmodell) - oder? Der Kasten müßte also mal überarbeitet werden (wie ohnehin eine ganze Reihe der Netzwerkartikel...)

Entsprechend fehlt der Kasten (und diese Einordnung) auch bei IGMP.

Ach ja, und bitte Beiträge unterschreiben und so :) -- Drbashir117 13:21, 5. Sep 2006 (CEST)

ICMP ist recht leicht inzuordnen, ich verstehe gar nicht, warum es darum so viel Verwirrung gibt. In jedem Sniffer kann man sehen, dass es auf Schicht 4 im OSI-Modell liegt. Auch im TCP/IP-Referenzmodell ist es auf der Transportschicht zu finden. Im IP-Header gibt es auch ein Feld ("Protocol"), in dem das nächst höhere Protokoll angegeben wird. Beispielsweise 0x06 für TCP oder 0x01 für ICMP (-- 87.78.75.94 21:02, 14. Mai 2007 (CEST))

Meiner Meinung nach ist ICMP eher auf Layer4 einzuordnen, auch wenn es nicht alle Layer4 Aufgaben erfüllt. Es ist eindeutig ÜBER Layer 3, da man damit den Layer3 und darunter testen kann (echo request/reply). Einmal abgesehen davon ist es im Layer3 als dafürliegendes Protokoll eingetragen (wie auch TCP/UDP).

64 Byte/Bit

Zitat: Oft werden ab dem zweiten Datenwort auch IP-Header des auslesenden Datagramms sowie die ersten 64 Byte des Pakets bermittelt. -- Sind das nicht 64 Bit? Also 8 Byte? -- (Vorstehender nicht signierter Beitrag stammt von 129.69.196.123 (Diskussion • Beiträge) 2006-02-23T15:52:10)

Da bin ich derselben Meinung. -- (Vorstehender nicht signierter Beitrag stammt von Vuk3k (Diskussion • Beiträge) 2006-05-14T11:44:35)

Das ist 64Bit, die den 64Bit von TCP-Header entsprechen. Diese Quelle enthält den Quellenport(16Bit), den Zielport(16Bit) und die Zeilennummer(32Bit). Das kann man sich auf der folgenden Seite ansehen:

http://www.faqs.org/rfcs/rfc792.html

Typ 3, Untertyp 4

Dieser Typ wird als Fragmentierung nötig, DF einstellen wieder gegeben. Das ist falsch bzw. wenigstens irreführend: eine Destination unreachable-Nachricht mit Untertyp 4 wird immer dann ausgelöst, wenn das Paket fragmentiert werden muss (weil zu groß), aber nicht fragmentiert werden darf, weil das DF-Bit gesetzt ist (DF = don't fragment). Ein besserer Text wäre z.B. Fragmentierung nötig, aber durch DF-Bit verboten.

-- Murdegern 10:41, 23. Mai 2007 (CEST)

Unvollständiges Aufbaudiagramm

Im Diagramm sind nur Typ(1B), Code(1B), Prüfsumme(2B) und Daten angegeben. Laut Ethereal sind aber noch Identifier und Sequence Number (jeweils 2B) enthalten. Ist auch logisch, weil sonst könnte man hinter einem PAT-Router ja überhaupt nicht rauspingen (rauspingen vielleicht schon, aber zurückfinden wird keiner). Weiters wäre es noch interessant, wie die Prüfsumme berechnet wird (einfaches XOR oder etwas komplizierteres).

Die Lektüre des zugehörigen RFC offenbart, dass diese Felder nur in einigen ICMP Typen so verwendet werden. Daher gehören sie meiner Meinung nach nicht in ein allgemeines Aufbaudiagramm. -- 91.16.89.87 07:56, 18. Feb. 2010 (CET)

ICMP-Header

Der im deutschen Text gezeigte Aufbau des ICMP-Header ist unvollständig...siehe englische Beschreibung von ICMP.(Der vorstehende, nicht signierte Beitrag stammt von 198.6.73.207 (Diskussion • Beiträge) 15:41, 24. Jul. 2008)

Ich habe im RFC 792 nachgeschaut. Der Header in der deutschen Wikipedia ist korrekt wiedergegeben. Was fehlt sind die IP-Header Informationen, was aber hier der Übersichtlichkeit dient. Im Englischen wird noch ein ID-Feld angegeben, dieser existiert aber nur bei der Information Request or Information Reply Message (Typ 15/16) Auch wenn es der am häufigsten verwendete Typ ist - im allgemeinen Fall können keine weiteren Angaben zum Datenbereich gemacht werden.--Merlissimo 16:29, 24. Jul. 2008 (CEST)

17 (!) Siehe auch Verweise

...muss nicht sein, oder? --Ponte 21:56, 8. Nov. 2008 (CET)

Keine ICMP-Message löst eine andere aus...

Es gilt der Grundsatz, dass ein ICMP-Paket niemals ein anderes ICMP-Paket auslöst

Es kann sich bei dieser Aussage ja wohl nur um einen blöden Scherz handeln - die meisten ICMP-Messages bestehen schließlich aus Request/Reply-Paaren. --217.6.251.18 13:35, 24. Feb. 2010 (CET)

Das denke ich auch. Es herscht vollständige Unabhängigkeit durch Request/Replay, wieso also diesen "Grundsatz" erwähnen? Besser wäre: Da sich das Verhalten im ICMP auf Request/Reply beschränkt, gibt es keine Abhängigkeiten unter den Paketen. --Faby90 16:06, 11. Mär. 2010 (CET)

Die Aussage ist aber richtig. Ein "Echo Request" z.B. löst nie ein "Host unreachable" aus. Höchstens ein "Echo Reply". Diese Ausnahme ist aber im Artikel erwähnt. --Krd 13:55, 12. Mär. 2010 (CET)

Knapp ein Jahr später... man muss da relativ genau auf das achten was da steht: "ANDERES-Paket"... oder besser gesagt einen anderen Paket-Typ. Gemeint ist, das eben z.B. ein Timestamp Request kein Information Reply auslöst --77.190.89.190 17:45, 19. Jan. 2012 (CET)

ICMP-Flooding

Kann jemand evtl. eine kurze Erläuterung hierzu in den Artikel einbauen? --Gruß asomy^disk 11:09, 25. Nov. 2013 (CET)

Ich habe es mal versucht ;-) Mirko (Diskussion) 02:19, 11. Feb. 2014 (CET)

Fehlende Belege im Abschnitt "Port Unreachable" mit Unterabschnitt "Firewalling: Port unreachable versus drop"

Im Abschnitt "Port Unreachable" und der Unterabschnitt "Firewalling: Port unreachable versus drop" fehlen Belege. Dabei wird die Frage drop vs. reject im Internet durchaus kontrovers diskutiert. Es gibt für beide Seiten Argumente, die dafür bzw. dagegen sprechen. Die Welt ist schließlich nicht schwarz-weiß.

Die Begründung zu den technischen und sicherheitsrelevanten Problemen ist aber zumindest teilweise falsch. Ich möchte das an einem Beispiel verdeutlichen: Bei einem Webserver wurde der Port 80 explizit geöffnet. Die Default-Policy ist DROP. Dann liefert nmap etwa folgende Ausgabe:

$ nmap -p 1- www.example.com

Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-16 23:48 CEST
Nmap scan report for www.example.com (1.2.3.4)
Host is up (0.042s latency).
Not shown: 65534 filtered ports
PORT      STATE SERVICE
80/tcp    open  http

Nmap done: 1 IP address (1 host up) scanned in 130.01 seconds

Daraus kann man keineswegs erkennen, dass auf Port 3306 ein MySQL-Server läuft.

Ohnehin ist fraglich, ob der Absatz überhaupt in den Artikel über ICMP behört. Meines Erachtens nicht. Er wäre im Artikel Firewall oder Firewall-Regelwerk besser aufgehoben. (nicht signierter Beitrag von Phantasmagorium (Diskussion | Beiträge) 01:02, 17. Mai 2015 (CEST))

Ich habe den Abschnitt nun gelöscht. Das gehört so nicht in einen Artikel zu ICMP und ist differenzierter im Artikel Firewall-Regelwerk beschrieben. (nicht signierter Beitrag von Phantasmagorium (Diskussion | Beiträge) 01:10, 25. Jul 2015 (CEST))

Kritik an der häufig empfohlenen Sperrung von ICMP (Stealt Mode, Ping sperren)

Erste Frage. Wozu willst du Ping blocken? ES macht schlicht & ergreifend keinen Sinn, auch wenn einem dass all diese So'n-Alarms dieser Welt glauben machen wollen. Was passiert, wenn ICMP-Ping-Pakete geblockt werden? Richtig: Keine Antwort. Was passiert, wenn der Computer aus ist? Das vorgelagerte Gateway schickt "ICMP: Destination host unreachable." Somit weiß ich immer ob ein Rechner da ist, egal ob du Ping blockst oder nicht.

Die Deaktivierung von ICMP (Ping) scheint keinen Sicherheitsgewinn zu bringen. 12:52, 13. Sep. 2015 (CEST) (ohne Benutzername signierter Beitrag von Europafan (Diskussion | Beiträge))