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 (Wireshark-Screenshot). (-- 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)