Diskussion:Internet Control Message Protocol

message: 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)
thread_title:  Typ 3, Untertyp 4 

message: 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)
thread_title:  Unvollständiges Aufbaudiagramm 

message: 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)
thread_title:  ICMP-Header 

message: ...muss nicht sein, oder? --Ponte 21:56, 8. Nov. 2008 (CET)
thread_title:  17 (!) Siehe auch Verweise 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Keine ICMP-Message löst eine andere aus... 

message: Kann jemand evtl. eine kurze Erläuterung hierzu in den Artikel einbauen? --Gruß asomydisk 11:09, 25. Nov. 2013 (CET)
thread_title:  ICMP-Flooding 

message: 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)
replies: text: 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)
thread_title:  Fehlende Belege im Abschnitt "Port Unreachable" mit Unterabschnitt "Firewalling: Port unreachable versus drop" 

message: 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)
thread_title:  Kritik an der häufig empfohlenen Sperrung von ICMP (Stealt Mode, Ping sperren) 

message: Das Internet Control Message Protocol (ICMP) dient in Rechnernetzwerken dem Austausch von Informations- und Fehlermeldungen über das Internet-Protokoll in der Version 4 (IPv4)
Ist
* Fehlermeldungen die das Internet-Protokoll betreffen oder
* Fehlermeldungen die über das Internet-Protokoll ausgeliefert werden oder
* beides
gemeint?!
Gruß, --Heronils (Diskussion) 13:08, 22. Feb. 2024 (CET)
replies: text: Beides: Fehlermeldungen, die das Internet-Protokoll betreffen und die außerdem auch über das Internet-Protokoll ausgeliefert werden. --Matthäus Wander 15:46, 22. Feb. 2024 (CET)
replies: text: Danke, Matthäus! --Heronils (Diskussion) 09:31, 23. Feb. 2024 (CET)
thread_title:  Wie ist "über das Internet-Protokoll" zu verstehen?